Debug Print
How many times you were trying to understand what’s going on in you app by print'ing variables in Xcode? There are many more ways to do it easily and professionally. Let’s review some of them.
print is a universal tool. But in most cases it’s not what you need. First of all to print something new you have to re-build and re-launch app. Second, accidentally leaving many print statements in code you simplify hacker’s life by unveiling inside world.
Of course, there is this debugPrint which won’t print anything to output in release mode. Yet it’s not what you probably need. You need…
Breakpoints
Breakpoints are really powerful tool ignored by many developers. Let’s create simple Single View App. Add a UITextField and UIButton. And bind text field and button press action:
Launch the app. Put breakpoint in function called on button press. Type something text field and press button. App stopped or entered a debug mode.
Now let’s print out entered text. Press right button on breakpoint. Choose Edit Brekapoint… press Add action and select Log Message. Enter the following text in Message field entered value = @inputField.text@
You might notice autocompletion while typing. Yes, it is also working here and it’s really, really helpful. Now, make sure your text field in app is empty and press button. You might see something like this:
App stopped, value printed. Stop! It’s not printed. It’s empty. We don’t need empty values. Let’s adjust our breakpoint to print only meaningfull messages. Edit breakpoint and add Condition
There is this nice Automatically continue after evaluating actions meaning “I will do all you wan’t me to do but won’t stop app” Really useful many times. As you noticed we also may print out counter for out breakpoint event (see %H on picture above). Or ignore it for X times (see Ignore <x> times before stopping value. Feel lonely? Ask you debugger speak messages instead of printing them (just choose Speak message instead of selected Log message to console). There are also other types of actions you may choose from:
I enjoy sound. Especially different sounds on different events. When debugging becomes musical performance :)
You’ve spent hours setting you breakpoints. Found all the bugs, fixed all the inconsistencies in code and… don’t want to loose those tiny helpers. Or even share them?!!
Yes. You may share breakpoints. By default those added to either project or workspace (about it a bit later) to user’s space i.e. stored in either in *.xcodeproj or *.xcworkspace folder in xcuserdata and user’s subdirectory. Many teams decide to add those directories to git ignore. But keep xcshareddata. Thus, sharing breakpoints (aka moving to shared folder) may be committed to git repository and re-used by colleagues.
There is also a moving option for breakpoints
You can choose where to store (and thus — apply) those breakpoints: in a project, a Workspace (applied to all projects in that workspace) or a User. Wait! How can a breakpoint be applied anywhere else but where it’s place?!! It turns out there are several cases when you wan’t to pause app running on certain circumstances. Open Breakpoint navigator (is 8th tab on the left side in Xcode window). On it’s bottom you may add several types:
Constraint Error Breakpoint is a good example of breakpoint which may happen on almost any screen :)
I hope this gives you an idea how you may improve you debugging experience and also save many hours to your colleagues. Enjoy!
P.S. Check demo project.
