Leave a rating/review
You’ve learned more about breakpoints, and using them to pause and continue code execution, but we still haven’t found what is causing the bugs in our project.
Unfortunately, I’m on the same boat here at home. I’m learning about tools and things I can do to find the source of the bugs in my house, but I’m not really addressing the issue.
There’s no way I can keep my home like this forever, and neither can you ship your app in its current, buggy, state!
In this episode, you’ll see how to view the values of variables in order to further understand what’s going on with your code.
There should not be any breakpoints in your project. If there are, or to double-check, verify against the Breakpoint navigator and make sure you remove them all.
Click on RowView.swift and set a breakpoint on line 42. Build and run your app, and let’s focus on the Debug Area.
On the left side you’ll see the Variables View. If you don’t see it, and ensuring the Debug Area is visible then click this button in the lower-right corner of the Xcode window to show the Variables View.
In here, Xcode uses the term variables generically to describe both variables and constants in your code. Xcode chooses the variables to show you based on where you’re paused. In a minute you’ll learn how to view exactly what you want.
For now, expand self by clicking the disclosure triangle to its left.
You’re now looking at the properties of RowView. Click the disclosure indicator for task, in order to view the details of your Task Binding. Next up, click the disclosure indicator to expand value.
Voila! We are now looking at an individual Task to be used in drawing the contents of RowView. Click Continue once and notice how the Task’s name property changes, but completed is, so far, always true.
I think this is the source of one of our bugs. A task should not start out as completed. Great detective work, fellow Detective Pikachus!
Let’s look further into this bug, and for that, I want to show you a little bit more about inspecting variables. Click on the task row inside the Variables View and then click on the small i button at the bottom. It should be next to a button that looks like an eye.
Clicking that button will cause a description of task to be printed to the console. You can manually accomplish the same thing on the right side of the Debug Area, using the Console.
Click anywhere inside the Console, on the right side of the Debug Area, and type the following:
po task
Hit Return and check out the results.You can remember this by thinking of po as standing for print object. This prints what’s called the debug description of the object.
In this case, the debug description of the task includes the id, name, and completes properties. You can also type out exactly what you’re looking for.
Type the following in the console:
po task.completed
Hit Return one more time and notice how your console prints out true. Another cool thing you maybe saw is that auto-completion works in the console too. Pretty nice!
Next, I want to show you about working with expressions in the Variables View.
With execution stopped at your breakpoint, right-click in the Variables View and select *Add Expression…*.
Notice how you are given the option to enter some text for your expression. Add the following line for your expression:
task.completed
Hit Return when done, and notice how your Variables View now shows the current task’s completed value, without you needing to work in the console or expand any variables inside the Variables View.
To delete your expression, simply select it and hit Delete on your keyboard. Alternatively, you can right-click the expression and select Delete Expression….
Expressions can be very handy if you want to save time while regularly inspecting values when breakpoints hit, or to avoid having to po items in the console.
You can change the values of properties while execution is paused. When you resume, your code will use the new values.
In the Console, type the following:
po task.completed = false
Then hit Return. It doesn’t look like anything happened, but go ahead and disable your breakpoints, click Continue, and take a look at your app.
Whereas before you had three rows with the triangle image, which is used to show the completed tasks, one of your tasks now has no icon because its completed property was just set to false.
It looks like one of the bugs is that tasks are showing up as completed by default, when what you want is to have them start our with completed set to false.
Open Task.swift and look at line 38. Aha! Every time a task is created it’s starting out with completed set to true. Change that line of code so completed is set to false:
var completed = false
Yay! The first bug has been fixed :) Be aware that changing your model object, or some other variable, can have an impact on how the rest of the code runs.
This is a pretty powerful tool for making changes without having to stop to modify code, but as uncle Ben always said: With great power comes great responsibility. Just know that if things misbehave somewhere down the line, it could be because of the changes you made when paused and not anything to do with an error in your code.
The final piece of advice for this episode is that it can be really helpful to construct your code in a way that makes it easier to inspect. What do I mean by that? Let’s take a look.