Xcode conditional break points

I’ve been developing for iOS for quite a while now and I’m always amazed at the things I don’t know that can really change my workflow. I’ve felt at home in the debugger for a while - printing objects and scalar variables, assigning values and generally navigating around fairly smoothly. Today I got a new tool to put in my programming belt with the knowledge that it’s possible to create conditional breakpoints - this is something that I wish I knew a long time ago.

##Problem in context

It’s a fairly common problem that you’ll have an issue that occurs only while in some kind of loop, whether it is a for loop or a user interaction loop of some kind e.g. tapping a button multiple times. It can be both tedious and error prone trying to get yourself set up to examine state when you have to perform repetitious work like pressing continue on the debugger. It’s easy to overshoot your assumed condition and have to start again or maybe it would just take far too long to get yourself in the correct state manually.

##Meet conditional breakpoints

Our test scenario is both silly and simple but it gives us something to work with.

“We have noticed that every 10th time through our loop we get an error - we would like to stop execution and examine our object.”

MyObject *myObject = [[MyObject alloc] init];

for (int i = 0; i < 1000; i++) {
  [myObject doSomething];        // Break point on this line
}

###The old way

We set up a break point and we are happy to click continue as we only have to do it a few times. Hopefully our counting and hand to eye co-ordination is up to standard and we manage to click through correctly the first time to get us in the right state

click: Run 
click: Continue    
click: Continue  
click: Continue  
click: Continue  
click: Continue  
click: Continue  
click: Continue  
click: Continue  
click: Continue  
click: Continue  
Examine the object

We “fix” the issue but now it happens every 100th time through the loop. At this point we would probably abandon our tools and deteriorate to caveman debugging. Log everything and then scan the logs to see what is happening… but luckily we don’t have to give up just yet.

##Conditions

If you right click the breakpoint in Xcode you’ll see an option to “Edit Breakpoint…”.

As you can see there are some interesting configuration options here.

• Condition - A condition to be met for the breakpoint to fire
• Ignore - Amount of times the condition needs to be met before firing
• Action - Any actions to run which can be Applescript, Capture OpenGL frame, Debugger Command, Log Message, Shell Command, Sound
• Options - As it says in the image

Remember using Debugger commands alone we can access all kinds of information like the values of variables, back traces etc

###Basic condition

To start we’ll set the condition and run an action to see if we can grab the 100th iteration

Side note - p i will just print the variable i

We hit run and sure enough the debugger stops and in our console we get output like:

(int) $101 = 100
(lldb)

###Basic condition with ignore

To try out the ignore option we’ll stop on the 5th time that i == i, which will leave us with a value of 5.

This gives us output like:

(int) $1 = 5
(lldb)

###Non trivial condition

The Condition expression can be non trivial as long as llvm can understand it. For example if I wanted to examine the state around my object when one of the properties is set to the string broken I can get the breakpoint to fire like this:

Apart from the annoying cast this is nice and clean.

##”But I really like caveman debugging…”

You may be thinking “this is cool but I can just write the code that will print things when different conditions occur” - and you’d be right. There are two reasons why I prefer using the conditional breakpoint

1. Where possible I don’t like changing production code for development purposes.
2. If I logged the object out I would only get the information that I logged. With the breakpoint I can examine all the state around the object as well because the execution is paused.

##Crazy thoughts

I’m still only thinking about the wide range of debugging possibilities available but one far fetched scenario that could have uses in a collaborative environment could be for capturing those bugs that are hard to reproduce.

By setting up a conditional breakpoint and sharing it with the team, you could have multiple workstations + multiple developers going about their normal work but potentially capturing that awkward code path that you can never quite reproduce. At this point you can literally do anything - dump everything to a log, run a script to email you information, have the computer say "STOP you've found the lochness monster bug", who knows what fun you could have.

##Conclusion

Conditional breakpoints are very flexible and powerful. Although I prefer to avoid the debugger by writing the best code I can, knowing how to use the tools effectively really helps out in times of need. Don’t be fooled by only having 4 options to configure, these give you amazing power and versatility and should help avoid the times when you are stuck caveman debugging large repetitive tasks.

Shared iOS projects with minimal setup

Sharing iOS projects can be a frustrating task. This has been greatly improved with tools like cocoapods maturing quickly. This certainly goes someway to alleviating the project sharing pain but we are not quite where I want to be. Cocoapods manages the Objective-C dependencies but a project may have other dependencies such as additional tools (often written in Ruby), which will have their own dependencies. I would often think it would be great if I could standardise my processes across my projects and add a simple of way of setting up a cleanly cloned project…

Then I remembered I post I had read called Setting up a new machine for Ruby development at 37signals.com about them having a rake setup task that would get your project set up and ready to run.

##A naive implementation

This got me to create my own simple rake setup task, here is the very simple script that saves a fair amount of bother when collaborating:

desc 'Set up project'
task :setup do
  sh 'bundle install'
  sh 'pod install'
end

This of course comes with some requirements on the target machine. I currently use Ruby 1.9.3 managed with RVM. The bundle install is not really required by I tend to use Ruby for other tasks in my projects and find it easier to have Bundler manage my Ruby dependencies.

##Piecing it all together

A full example of working on a project with this in place is as simple as

git clone {Some git repository}
rake setup

##Conclusion

It really is worth making sure that your projects can be easily shared and set up. Using tools that are widely available always seems sensible, but in this case it does require that the target environment is suitable e.g. has ruby, rake and bundler.

Working with hex colours

We’ve all been there when a designer has passed over the colours to be used in our application only to find that they have given us the value in hex. This means we now have to scramble to open our HexToRGB application or include some convoluted category on UIColor that adds a bunch of methods doing a load of calculations. The majority of the time adding these helper methods to UIColor is likely us just being heavy handed. The task can have a much simpler resolution.

##Solution

So our designer has just finished perfectly tweaking his palette and has given us #66CDAA for that “Medium Aqua Marine” colour we so badly needed. As our application will have a selective palette of colours I would still take the opportunity to create a category with factory methods for creating the different palette colours. Our “Medium Aqua Marine” might look something like this

@interface UIColor (ApplicationPalette)

+ (UIColor *)ps_mediumBackgroundColor;

@end

@implementation UIColor (ApplicationPalette)

+ (UIColor *)ps_mediumBackgroundColor;
{
  return [self colorWithRed:0x66/255 green:0xCD/255 blue:0xAA/255 alpha:1.f];
}

@end

The beauty of this snippet can easily be overlooked on first glance. Take note of the fact that I have just preceded the hex value with 0x so that C knows that we are talking in terms of hex. Also note that I tried to avoid using the colour name in the category, this means that I can change the palette colour to be a medium red and not have to find everywhere that I previously used the category that referenced the colour green in the name.

##Conclusion

This may seem like a trivial snippet but you’ll appreciate the technique when you have the designer sat over your shoulder rapidly barking out hex values as they try to get the maximum effect from their design when deployed to the actual hardware. Also note the usefulness of being DRY and writing this category so that we don’t need to search every in our code to make small tweaks to out palette.