Learn tips for debugging your code and fixing errors in Thunkable
These are the activities for this lesson:
WHAT IS DEBUGGING?
Debugging is the process coders use to figure out why their code isn’t working, and then fix it so it does work.
The term debugging came from Admiral Grace Hopper, a pioneer in computing. She was working on the Mark II computer at Harvard University in the 1940s and a moth got stuck in the computer and stopped it from working.
Getting rid of the moth, she said they were “debugging” the system. Programmers use the term now to mean “fixing errors in my code”.
CODING TIPS
Debugging can often be the most frustrating and time-consuming part of coding, so it’s really important to leave plenty of time for it!
And also to be patient!
SMALL CHUNKS
Sometimes programmers are tempted to code their entire app in one go, then test it.
Don’t fall for that temptation!!!
If something doesn’t work correctly, which is likely, it’s hard to figure out where to even start to try to fix the error.
Break the coding for your app into small chunks.
Get one thing working before starting on the next thing.
Code a little bit, test a little bit, confirm it works, then code a little more, test a little more, etc.
For example, if your app has 5 buttons that all do different things,
- Code the action for the first button
- Then test to make sure it works.
- Move onto the second button
- Repeat.
It’s better to fix code in one place than go back and fix it in 5 places if there is an error in your code.
VERSION CONTROL
Let’s say you follow the “small chunks” rule and have one part of your app built and working.
You add some new code and suddenly everything stops working.
OH NO!
You try to delete the new code but your app still isn’t working. You aren’t sure what went wrong and wish you had an “undo” button.
To avoid scenarios like this you can save versions of your app as you get parts working.
That way if you make a mistake and don’t know how to fix it, you can go back to the last working version you saved.
You can also use version control to experiment with new features without worrying about breaking your working app.
The free version of Thunkable has a 10 project limit, so if you reach your project limit, you can delete the oldest versions before saving a new one.
To make a copy of your project:
- click on the 3 dots in the upper right corner of the screen
- Select “Duplicate Project” from the dropdown.
- Rename your saved copies to keep track. Numbering v1, v2 works well.
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 Alerts.
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. They will appear greyed out. You can always snap them back in to enable them again.
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.
Mentor Tip
Best practices: Comments are the most helpful thing in programming.
There have been many times when a coder has coded something and then gone to sleep and come back the next morning and have no clue about what they were doing the night before. Always write comments!
It’s also a great way to check your knowledge, because if your coding blocks are easy to comment on then you must understand them really well! Another thing to be aware of is that <, >, =, ≤, ≥ are hard for students for the first time (and for programmers who are years into their careers). When we set a math statement to < when it should be ≤ this is called an “off by one” error and this is a problem that happens to developers with 20 years of experience 😛 It is a very popular problem so be on the lookout for that.
The best type of debugging is rubber duck debugging! This is where you are really stuck in your code and it makes no sense. You want to take some time to talk through it with someone else to see if they can spot the problem but unfortunately no one is around! So you have a trusty rubber duck at your desk and you explain the problem outloud to your duck friend. You have to do it in very simple terms for them to understand though and then after that you will find the problem yourself! All of my coworkers do have rubber ducks at our desks and do this quite often!
Guiding Questions to ask students: How long do you think it takes experienced coders to debug bugs? You would think they could get really fast at it but each big site has pages dedicated to seeing how long bugs are in existence (Facebook for example) and they will also show if any of their pages are down/broken and they are currently debugging (Facebook example).
How do you find bugs? (lots and lots of testing!) How much testing do you think you should do? How much testing should you get other people to do?
How do you know when you have found a bug? Sometimes you may spend forever clicking on an image only to realize that the button you’re supposed to be clicking is under the image. Is that a bug? It’s a design choice that the app maker made and they don’t think it is a bug but you might.
Mentor tips are provided by support from AmeriCorps.
DEBUGGING TIPS
ALERTS AND LABELS
You can use components, like Alerts and Labels to display information as you test. Once you have fully tested the app, you can just remove them
You add an Alert in the Blocks window by clicking the + sign next to Alerts in the Palette.
Set the Alert Message to the information you want to track.
Then use Alert.Show in your code to display when an event happens.
In addition to messages, you can display information like the value of a variable or the position of a Sprite.
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.
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.
CHANGE PROPERTIES
If you are live testing your app, you can change a property value in the Designer while you run the app and see its effects.
Sometimes this can help uncover an issue.
For example, you might be coding a game. A sprite’s position doesn’t look right to you on your phone when it’s running.
While live testing, you can
- Go to the Designer
- change the X and Y values of the Sprite
- The position of the Sprite on the screen in the running app will change.
Use this to test and understand coordinates on your screen.
ACTIVITY 1: FIX THE BUG
Fix bugs in the Timer App
- Copy the project.
- Preview the app to run it.
- Try pressing Start without typing anything into the textbox. What happens?
- Try entering 0 or a negative number for number of seconds. What happens?
- Fix the bugs using conditional blocks!
ACTIVITY 2: ADD A COMMENT
Add a comment to your Thunkable project
Add at least one comment to your app explaining what a group of blocks does. Pick a group of blocks that you think it is the hardest to understand because those blocks would probably be the hardest for someone else, like a team member, to understand.
REFLECTION
These tips can help you as you start to code your mobile app for your Technovation project.
But remember…
REVIEW OF KEY TERMS
- Debugging – the process coders use to figure out why their code isn’t working and fix it
- Version Control – saving working versions of your app as you make progress
- Test data – a simpler set of data that you can use to make sure your app is working correctly
- Comments – text that is included in code to explain what it does
ADDITIONAL RESOURCES
Here are some more Thunkable debugging resources.
