/Inspecting Variables with LLDB – Intermediate Debugging in iOS – raywenderlich.com

Inspecting Variables with LLDB – Intermediate Debugging in iOS – raywenderlich.com

Video: Inspecting Variables with LLDB – Intermediate Debugging in iOS – raywenderlich.com


(upbeat electronic music) – In the variables view Xcode will show you the value of variables local to where you're currently paused. And you can draw down from there to get at properties from those variables. But often it's quicker and easier to just tell the debugger to print out the data that you want. There are three main ways to print data and they each have their own advantages and disadvantages. The three ways to view data are PO, P and FRV which is shorter for frame variable. There are a couple key differences between these. In what format they use to print data and what possible side effects they have on your app state.

The PO command uses the debug description method of the custom debug strain convertible protocol to format relevant data from the object. Both the P command and the FRV use built-in formatters to display the data. However both PO and P have the possibility to introduce side effects into your debug session. So you have to be a bit careful with them. FRV has no side effects but it's much more limited as a result. Open up the starter project for this video then open cat feed view controller. Remember sometimes debugging tools are useful just for understanding what's happening in your code. So set a break point at the end of self row at index path and let's see how these commands work. Build and run And when the debugger stops at the break point you're going to type some debug commands into the debug console. If this isn't showing first make sure the debug area is visible. And if it's not click this button. And then make sure the console is visible by clicking this button.

READ  Clearing a Paper Jam from the Scanner - HP Officejet 150 Mobile All-In-One Printer

First lets look at the PO command. Type this into the console. For this command the UI label class runs its debug description method which returns a string that is printed to the console. The class decides which data is most likely relevant like the text property and the frame and things like that. Now let's try the P command. This time the debugger uses built-in formatters to display the properties of the label. If this looks familiar its the same properties you see in the variables view when you draw down to the label on the cell. You might think of P as standing for print but type help P in the console. You'll some usage information but here at the bottom you'll see that P is an abbreviation for expression. That means you can use it to execute methods, not just print data. This is why it's possible to create side effects with these commands. Try this. Now you'll use the LLDB command to continue. This is the same as clicking this continue button.

It's up to you which is more convenient for you. In the console type C and press return. The app now crashes. By clearing the feed you put the app into a state that it didn't expect. Where the table view is requesting data on cells where the data doesn't exist anymore. Even if you're not intentionally running methods it's possible the property accessor for a piece of data you're viewing would have some side effect. Now let's run again just to get our state back to a good state. And this time when the break point hits type this. This uses the same built-in formatters to show the label. But try this. The response you get is that clear feed is not a member of self.photofeed. By that the debugger means it's not a data member. Both the PO and the P commands are abbreviations for expression which means they run code in a scope created by the debugger. They get all the advantages of your code including inference of self when accessing properties and things like that. But FRV is not running code. It's only inspecting data.

READ  New Green Star Elite GSE-5050 & The Best Tribest Juicer

So it's safer but as you can see more limited..