• Breakpoints: Debugging like a Pro
  • Originally written by Alan Ostanik
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: PTHFLY
  • Proofread by: Ryouaki

Breakpoints: Debug code like an expert

When I first started out as an iOS developer, my biggest problem was this: WHEN apps crashed, I really didn’t know how iOS, Swift, Objective-C all worked. Back then, I wrote a lot of bad code and never worried about memory usage, memory access, and Automatic Reference Counting. That’s only because I don’t know those things. I’m a rookie, for God’s sake.

Like many newcomers, the Stack Overflow community has taught me a lot about “how to do the right thing.” I’ve learned a lot of tips to help improve my work process. In this article, I’ll share some of the most important tools in this phase of the process, which are breakpoints!

Well, roll up your sleeves and get to work. 🙂

The breakpoint

There is no doubt that Xcode breakpoints are a powerful tool. Their primary purpose is to debug code, but what if I said they do more than that? OK, let’s start with some tips.

Conditioning BreakPoints Conditional breakpoints

Maybe you’re already in a situation where your TableView works fine for all the user models, but there’s one that’s causing some trouble. To debug this instance, the first thing you might think is, “Ok, I’ll make a breakpoint where the cell is loaded and see what happens.” But for each cell, even the temporarily normal ones, your breakpoints are activated and you have to keep skipping until you get to the one you want to debug.

To solve these problems, you can go ahead and set a stop condition to the breakpoint, as I did with the user “Charlinho”.

Symbolic Breakpoints Indicates Breakpoints

“Relax, I’ll use pod, that should save us some work.”

There’s no guarantee you’ll never say it again. But using a POD or an external library means that you are introducing external code to your project and you may not know how it was written. Let’s say you find a bug in a bunch of methods inside pod, but you don’t know where the method is. Take a deep breath and stay calm. Do you have * * — Breakpoints * *.

These breakpoints are activated when the pre-declared flags are awakened. The flag can be any nonmember function, instance, class method, or not in your class. So by adding a Breakpoint to a function, no matter who wakes it up, you simply add a Symbolic Breakpoint to observe the function you want to debug. In my sample, below I observe UIViewAlertForUnsatisfiableConstraints method. This method is invoked every time Xcode finds an Autolayout problem. You can check out this blog post for a more in-depth example.

Customizing BreakPoints Customizing breakpoints

As I said earlier, breakpoints are a powerful tool. You know what? You can even customize actions on endpoints. Yes, you can! You can run AppleScript, capture CPU frames, use LLDB (low-level Debugger) commands, and even shell commands.

You simply click the button on the right and select Edit BreakPoint.

Okay, you look and think, “Cool! But why?”

I’ll give you a good use case to help you understand. The most common feature in an APP is login, which is sometimes a little boring to test. If you’re using both an administrator account and a regular account, you’ll have to constantly enter a user and password, which can make the process unbearable. A common way to “automate” the login page is to create a mock instance and apply it to the if Debug clause. Like this:

struct TestCredentials {
    static let username = "robo1"
    static let password = "xxxxxx"
}

private func fillDebugData() {
     self.userNameTxtField.text = TestCredentials.username
     self.passwordTxtField.text = TestCredentials.password
}
Copy the code

But you can make things a little easier with breakpoints!

Go to the login page, add a breakpoint, and then add two LLDB expressions to fill in the account password. Like my example below:

With this in mind, you can add two breakpoints for different identities. You just activate/disable the one you want to test, and you can switch between the two identities. Once you switch users on the fly, there’s no need to rebuild.

Cool, isn’t it?

COMBO BREAKER!

As I write this, WWDC 2017 is taking place. They released some cool stuff like the new Xcode 9. If you want to know what new debugging tools are available in Xcode 9, I highly recommend looking at Session 404.

That’s all! Now you know some of the most basic breakpoint tips that helped me a lot when I was a beginner. What other cool tricks haven’t I mentioned? You have a good idea, too? Feel free to discuss in the comments section!

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.