Debugging & Best Practices - Learn SpriteBuilder for iOS Game Development - page 473

Figure 14-6 . A breakpoint halted program execution
Below the source code window, you'll find the Variables View , where you can inspect the
values of variables. By default, Xcode will show you the self-reference if the app halted
anywhere within an Objective-C instance method, plus any local variables and those being
used by the surrounding code. You can change this behavior by clicking on the Auto drop-
down menu in the lower left corner of Figure 14-6 . Also, note that the Console view is
hidden. You can change the visibility of Variables and Console views with the two icons
in the lower right corner.
So, despite this being a pretty obvious problem, let's try and debug why _playerNode
might be nil . The breakpoint was set, and the app ran up until this point. You can clearly
see in the Variables View that the _playerNode variable points to a valid object. You
can unfold the object to see more of its properties and ivars, but that's not really the point.
What I like to show is how you can run through your code line by line, which allows you
to see how variables change after each line and what conditional path is taken and why.
Figure 14-7 highlights the debug toolbar that's also in Figure 14-6 .
Figure 14-7 . The debug toolbar
From left to right, the first button hides the debug area, and the second shows you whether
breakpoints are globally enabled or not. If it's not highlighted in blue, no breakpoints will
trigger. The third button pauses and resumes program execution. You normally use it to
continue running the app to the next breakpoint (if any) after a breakpoint was triggered.