Breakpoints

This post is all about the “console” in Xcode. The area of the Xcode interface that pops up when you run your app using the “Run” scheme which outputs your NSLog statements. This is all fine and dandy but when your code hits a breakpoint thats when the magic happens. The console turns into a prompt and is ready to accept commands. Before learning how to use the console you need to know how to set a breakpoint. Luckily its incredibly easy!

A breakpoint is a place where the debugger will stop the code running when the path of execution gets to that point. From the breakpoint you can then inspect the runtime and even execute the next satements one by one, helping you to understand what is happening in your code. To set a breakpoint you find the line of code you would like the debugger to stop at and click next to that line in the gutter of the xcode editor window.

You can also set breakpoints to stop code based on symbols you dont have in code you can edit, like framework symbols, by setting a symbolic breakpoint in the Xcode breakpoint navigator.

To set a symbolic breakpoint click the plus button in the lower left hand corner and click “Add Symbolic Breakpoint”. You then enter a symbol in the form suggested by the popover:

1
2
3
4

    //For instance methods:
    -[NSClassname some:selector:with:args:]
    //For Class Methods
    +[NSClassname someClassMethod:withArgs:]

You can also set a breakpont for exceptions, stopping the code at the point the exception is thrown rather than when the app terminates due to the exception being thrown. You do this from the same add button, instead selecting “Add Exception Breakpoint”.

po

So your code hits a breakpoint. What next? Xcode will show you all the variables in scope in the right hand “Variables View” of the debugger pane that pops up from the bottom. In Xcode 5 this view has gotten some really impressive quicklook features but thats all point and click. I’m here to tell you about some commands that you can run in the debugger area. If your code is stopped at a breakpoint you will get the lldb prompt:

1

(lldb)

Rather unassuming. The first command we will try is po. po prints out objective-c objects. Well technically it prints out the result of the -(NSString*)description method defined on NSObject. How useful that information is is up to the developer of the class you are printing. You can print any variables in scope by typing po <variablename>

Great! Most Apple classes have some great descriptions. You can also print the result of methods on your classes if those methods return Objective-C Objects. The debugger will call -(NSString *)description on the results of that method and print that. Example:

1
2
3

(lldb) po [UIApplication sharedApplication]
<UIApplication: 0xb074780>
(lldb)

Not the most useful result. Lets chain some messages together and see what happens:

1
2
3

(lldb) po [[[UIApplication sharedApplication] delegate] window]
<UIWindow: 0xb2b3340; frame = (0 0; 320 480); opaque = NO; autoresize = RM+BM; layer = <UIWindowLayer: 0xb2b3440>>
(lldb)

Excellent! We’ve printed the description of the main window. Heres a cool snippet that can help you debug your view heierarchy from anywhere you break in your app:

1
2
3
4
5
6
7
8
9
10
11
12
13

(lldb) po [[[[UIApplication sharedApplication] delegate] window] recursiveDescription]
<UIWindow: 0xb2b3340; frame = (0 0; 320 480); opaque = NO; autoresize = RM+BM; layer = <UIWindowLayer: 0xb2b3440>>
   | <UIView: 0xb07c6b0; frame = (0 20; 320 460); autoresize = W+H; layer = <CALayer: 0xb07c710>>
   |    | <UIImageView: 0xb07c740; frame = (0 0; 320 460); autoresize = H; userInteractionEnabled = NO; layer = <CALayer: 0xb07c7a0>>
   |    | <UIView: 0xb07bb10; frame = (0 -88; 320 248); alpha = 0; autoresize = W+TM; layer = <CALayer: 0xb076bf0>>
   |    |    | <UIImageView: 0xb077490; frame = (196 51; 102 55); transform = [1, 0, 0, 1, -45, 0]; clipsToBounds = YES; opaque = NO; animations = { transform=<CABasicAnimation: 0xb07b630>; }; layer = <CALayer: 0xb076700>>
   |    |    | <UIImageView: 0xb078ba0; frame = (254 151; 88 30); transform = [1, 0, 0, 1, 28, 0]; clipsToBounds = YES; opaque = NO; animations = { transform=<CABasicAnimation: 0xb07cb20>; }; layer = <CALayer: 0xb078c00>>
   |    |    | <UIImageView: 0xb079ae0; frame = (176 130; 66 30); transform = [1, 0, 0, 1, 41, 0]; clipsToBounds = YES; opaque = NO; animations = { transform=<CABasicAnimation: 0xb07cce0>; }; layer = <CALayer: 0xb079b40>>
   |    |    | <UIImageView: 0xb07aa00; frame = (5 179; 64 30); transform = [1, 0, 0, 1, -49, 0]; clipsToBounds = YES; opaque = NO; animations = { transform=<CABasicAnimation: 0xb07d3b0>; }; layer = <CALayer: 0xb07aa60>>
   |    |    | <UIImageView: 0xb077a10; frame = (37 37; 93 43); transform = [1, 0, 0, 1, 28, 0]; clipsToBounds = YES; opaque = NO; animations = { transform=<CABasicAnimation: 0xb07c960>; }; layer = <CALayer: 0xb077a70>>
   |    |    | <UIImageView: 0xb07b990; frame = (-49 108; 88 30); transform = [1, 0, 0, 1, -21, 0]; clipsToBounds = YES; opaque = NO; animations = { transform=<CABasicAnimation: 0xb07d570>; }; layer = <CALayer: 0xb07b9f0>>
   |    | <UIView: 0xb07c620; frame = (0 0; 320 460); autoresize = W+H; layer = <CALayer: 0xb07c680>>
(lldb)

Printing Pointers

So if we look at the last example, what if I want to print information about the layer of the window? I could totally do this:

1

(lldb) po [[[[UIApplication sharedApplication] delegate] window] layer]

OR I could take the pointer referenced in the previous printout and po that instead:

1
2
3

(lldb) po 0xb2b3440
<UIWindowLayer:0xb2b3440; position = CGPoint (160 240); bounds = CGRect (0 0; 320 480); delegate = <UIWindow: 0xb2b3340; frame = (0 0; 320 480); opaque = NO; autoresize = RM+BM; layer = <UIWindowLayer: 0xb2b3440>>; sublayers = (<CALayer: 0xb07c710>); clearsContext = NO; backgroundColor = <CGColor 0xb2b3a00> [<CGColorSpace 0xb279620> (kCGColorSpaceDeviceRGB)] ( 1 1 1 1 )>
(lldb)

You can even send messages to the object at that pointer like you would a named variable:

1
2
3

(lldb) po [0xb2b3440 delegate]
<UIWindow: 0xb2b3340; frame = (0 0; 320 480); opaque = NO; autoresize = RM+BM; layer = <UIWindowLayer: 0xb2b3440>>
(lldb)

You can also even aritrarily pause the execution of your app using the pause button (where the continue button is when your app hits a breakpoint) and po that variable, or some property of it without even needing a breakpoint! Just remember that pointers will probably change from run to run of your app.

Rinse and Repeat

Pretty short section but its worth mentioning that like in a terminal, hitting the up arrow will cycle through your debugger command history. That is all!

Printing Core Foundation Things

So this is all great until you want to print a CGRect, CGPoint, or even a CGAffineTransform. In fact any of the C-struct style objective-c things we pass around can also be printed out by the debugger really easily. The long command is print but you only need to type p. This time, however you need to tell the debugger what kind of struct you are expecting to get a decent output. Its easier to demo this feature than to explain it so I put a breakpoint inside -(void)viewDidAppear:(BOOL)animated of a UIViewController. Lets see what debugger magic I can work:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

(lldb) p (BOOL) animated
(BOOL) $0 = NO
(lldb) p (CGRect) [[self view]frame]
(CGRect) $1 = origin=(x=0, y=20) size=(width=320, height=460)
(lldb) p (CGAffineTransform) [[self view] transform]
(CGAffineTransform) $2 = {
  a = 1
  b = 0
  c = 0
  d = 1
  tx = 0
  ty = 0
}
(lldb) p (CGFloat) [[self view] alpha]
(CGFloat) $4 = 1

Easy to use and awesome.

Hopefully these simple tips can help make your life debugging easier!

To recap the old way of subscribing to NSNotifications from an NSNotificationCenter was like this:

1
2
3
4

NotificationCenter defaultCenter] addObserver:self
                                     selector:@selector(someSelector:)
                                         name:NSSomeNotificationName
                                       object:nil];

This method is not without its problems in the current versions of Xcode. For example if one was to use the Refactor Rename tool it doesn’t automatically rename the selector in the @selector() block. Currently Xcode only suggests the changes.

Secondly you will appear to have a dead method when using the Xcode Callers list. The Callers list shows all the methods across the project that call that particular selector. When set as the selector of a notification it wont show in the callers list. While it may be obvious you intend the method to fire as a result of a notification you would still have to search for the notification listening code to find out if it existed and the :(NSNotification *) parameter is optional.

Thirdly this method is more crash prone. If the observer is deallocated without you calling [[NSNotificationCenter defaultCenter] removeObserver:self]; your app will crash. Admittedly in the scope of NSNotificationCenter observers this can be a good thing, alerting the programmer to a forgotten call to removeObserver: but its not a good bug to have slip through QA and land infront of users when theres an alternative that can fail silently.

The Modern Way

So the “new” alternative (Available in iOS 4.0 and later) is the following:

1
2
3
4
5
6

id observer = [[NSNotificationCenter defaultCenter] addObserverForName:NSSomeNotificationName
                                                                object:self
                                                                 queue:[NSOperationQueue mainQueue]
                                                            usingBlock:^(NSNotification *note) {

                                                                }];

The first thing you might notice is that you supply a block that is invoked when the notification is fired. You can also specify a queue for this to be executed on. Compared to the old method which will call all observers in turn and wait for their methods to finish before calling the next one queueing these blocks will exit immeadiately, even when queued to run on the main thread. If you know the work in the block will take time you can even farm it off to another queue right in the listener method.

But what about that wierd observer object. The method returns an object of opaque, unspecified type that you have to keep around. The reason is that your class is no longer the observer here, the returned object is! This is why this new method can fail silently if the end recipient of these notifications, self, gets deallocated without calling removeObserver:, the new observer object is actually retained by the notification center and will stay around.

Caveats

There are things you need to know to use this new method. First of all that observer object is your responsibility. You have to keep a reference to it around and eventually remove it from the NSNotificationCenter by calling [[NSNotificationCenter defaultCenter] removeObserver:observer];. I like to have a lazily created mutable array that I use to store observers, and then I can unsubscribe from them all in one go when needed using something like this:

1
2
3
4

    for (id observer in self.observers) {
        [[NSNotificationCenter defaultCenter] removeObserver:observer];
    }
    self.observers = nil;

The second caveat is down to block memory semantics. That block behaves like all others and retains everything in its scope. This means that if you rely on removing observers in the dealloc method, for example, it may never get called. It also means that, if you forget to remove the observer, whatever you reference in that block will be retained, sit there in memory and potentially execute its code in total isolation. This can cause untold trouble and hard to debug problems. The solution is to make sure that all references to self in the block are weak:

1
2
3
4
5
6
7
8
9

    __weak JPCloudViewController * weakself = self;
    id observer = [[NSNotificationCenter defaultCenter]
                    addObserverForName:UIApplicationDidEnterBackgroundNotification
                    object:nil
                    queue:[NSOperationQueue mainQueue]
                    usingBlock:^(NSNotification *note) {
                        weakself.cloudContainerView.alpha = 0.0;
                    }];
    [self.observers addObject:observer];

Now if the notification is fired and your object is released all the references to self will be nil and nothing will happen. No crashes or anything.

So why is it better?

Finally heres why I think the new syntax is better. Firstly programmer error will not cause a crash for users. Arguably it would be better to know about programmer error but I think an a memory leak is a better experience than a crash for the end user. If you wanted you could even put an NSAssert in the block to throw if weakself is nil. Assert macros are off by default for release builds so you can get the best of both worlds. Another benefit is you define the code to execute where you listen for the notificaion. The Xcode refactor tools work properly with the code in the block. The Callers list also shows correctly for functions called from the block. Code is guaranteed to run on the queue you specify, unlike the older style of notificaion where your code would run on the same thread that posted the notification. I also like the way blocks can be offloaded to background threads with ease.

Its good to try new things so give the new Notification syntax a try today!

privateQueueContext

The old model with NSManagedObjectContext was that you had to create a context on every thread you were going to access core data on. When this context was saved it would write back to the persistent store and notifications would fire that would allow you to update your other contexts on other threads.

The new model changes all this and makes working with core data on other threads easy. In fact instead of thinking in threads its better to think of everything in Queues (its based on GCD. You create a context for working on the main queue with like you normally would but you use the following new method:

1

NSManagedObjectContext * mainQueueContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];

There are many methods you can use to share this context among your view controllers like pass the baton, using the app delegate or a shared instance of your store object in a model-view-controller-store style project. Whats best is really a personal choice.

But the exciting part is how you work with core data in the background. Create a context with the private queue concurrency type like so:

1

NSManagedObjectContext * priveteQueueContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];

I like to keep this context private within a store object, since I mostly use the background thread for data processing and most of that happens within the store or its scope. One can then submit work to be done asyncronously in the background like so:

1
2
3
4
5
6
7
8
9

[self.privateQueueContext performBlock:^{
        Magazine * magazine = (Magazine *) [self.privateQueueContext objectWithID:magazineObjectID];
        magazine.headerImage = image;
        NSError * error;
        [self.privateQueueContext save:&error];
        if (error) {
            //handle error
        }
    }];

Queueing things up

Queues can give you some quite complex behaviour. Say you want to add a bunch of objects to Core Data and then save at the end. You send off several worker blocks, one to add each item, and then add block at the end that saves all the objects. No need to keep track of state or figure out when you are on the last object.

You can import a bunch of objects into core data, and then add a block at the end which works with all the objects you just added. This can be really helpful for importing objects and then adding relationships between them once they are all imported.

Syncing across

The only issue is syncing your changes made in the background to your foreground context. Listening to the notificaiton is fairly simple:

1
2
3
4
5
6
7

id observer = [[NSNotificationCenter defaultCenter]
                   addObserverForName:NSManagedObjectContextDidSaveNotification
                   object:self.privateQueueContext
                   queue:[NSOperationQueue mainQueue]
                   usingBlock:^(NSNotification *note) {
                       [self.mainQueueContext mergeChangesFromContextDidSaveNotification:note];
                   }];

If you are ever in the middle of a project and want to write a quick snippet to determine if an API is going to respond the way you think it will then Code Runner can help you out. Quite simply it sets up an environment where you can just start typing in your language of choice and, when you’re ready to test, has a giant play button similar to Xcode that will run your code.

Heres an example from the other day. I wanted to do a check on the iOS system version for a very particular edge case and I was browsing through all the terrible and overly complicated comparison functions proffered in this Stack Overflow Question and came across the option of using the built in NSNumericSearch option for compare:options:. I wanted to verify this method would work correctly with different version numbers so I fired up code runner and tried out this small programme with a few different version numbers

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

#import <Foundation/Foundation.h>

int main(int argc, char *argv[]) {
    @autoreleasepool {
        NSString * version1 = @"1.9.1";
        NSString * version2 = @"1.100.1";

        NSComparisonResult result = [version1 compare:version2 options:NSNumericSearch];

        if (result == NSOrderedAscending){
            NSLog(@"Ascending");
        }
        else if (result == NSOrderedSame){
            NSLog(@"Same");
        }
        else{
            NSLog(@"Decending");
        }
    }
}

Very quickly I had determined that the option worked as advertised and was able to include it in my code with the relevant test cases.

Debugging

If you make a typo in Code Runner it can be hard to debug as you dont necessarily get a stack trace or other information on code crash. Luckily Code Runner has the option to add custom running environments to its editor and by duplicating and slightly tweaking the existing objective-c template I was able to make it run the code in the lldb debugger.

When you click the play button it fires up lldb and will load your executable. To run you can type r and hit return. You can also use all the other lldb commands you would expect like add breakpoints and inspect variables at runtime. Its not as nice as the interface in Xcode but the liklihood is that the issues you will encounter wont be as hard to debug!

Classes, Protocols, Categories and more

I’m not sure its widely known that we keep our classes in separate files out of convention rather than necessity but with this knowledge your use of Code Runner can become quite advanced indeed. It can be used to prototype classes and methods on those classes that can quickly be integrated into a larger application. It can even be handy if practising computer science style challenges.

Heres an example where I was practising determining if a string was a permutation of another string. This is more of a trick question as once you realise that all permutations of any particular string are contained in a doubled version of that string the implementation is straightforward. Here I’ve implemented the check in code runner but as a category method on NSString

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#import <Foundation/Foundation.h>

@interface NSString (permutation)
-(BOOL)isPermutationOfString:(NSString \*)string;
@end

@implementation NSString (permutation)
-(BOOL)isPermutationOfString:(NSString \*)string{

    NSString * doubleSelf = [self stringByAppendingString:self];

    NSRange range = [doubleSelf rangeOfString:string];
    if (range.location == NSNotFound) return NO;

    return YES;
}

@end

int main(int argc, char \*argv[]) {
    @autoreleasepool {
        NSString * permutation = @"elloh";
        NSString * test = @"hello";

        NSLog(@"%@",[permutation isPermutationOfString:test] ? @"YES" : @"NO");
    }
}

So I reccommend you check out Code Runner. Its well worth the money and it can save you time with your development.

The interview quetion usually asks candidates to to determine, given a 4x4 boggle board, whether a given word is in the board.

The problem seems deceptively simple but the requirement that you mustnt revisit a letter means that any kind of recursive solution is going to have to keep track of a whole bunch of state and get messy really quickly.

Graph Search

The simplicity of a graph search based solution becomes apparent if you solve the meaty part of the problem first.

To solve this problem with a graph search algorithm we need the letters in a graph. Lets create a node object that we can build a graph out of:

1
2
3
4

@interface Node : NSObject
@property (nonatomic, strong) NSString * letter;
@property (nonatomic, strong) NSMutableSet * adjacentNodes;
@end

We would create a Node \* for each letter in the boggle board and then link it to the nodes that letter is adjacent to. There is now no need to store the Nodes in an array matrix that represents the board or anything like that as all the information about the board we need is encapsulated in these two pieces of data. Now assuming we can get the board represented in a bunch of Node objects all in an NSSet the algorithm for searching through them is relatively simple.

We take each Node in turn and do a depth first search on its neighbours for a match for the next letter in the word we are checking for.

1
2
3
4
5
6
7
8
9
10

BOOL searchForWord((NSString \*)word, NSSet * nodeGraph){
    NSString * firstLetter = [NSString stringWithFormat:@"%c",[word characterAtIndex:0]];
    for (Node * node in nodeGraph){
        NSMutableSet * visitedNodes = [[NSMutableSet alloc] initWithCapacity:word.length];
        BOOL found = depthFirstSearch(node, word, 0, visitedNodes);
        if (found) return found;
    }

    return NO;
}

For the depthFirstSearch function we need to do a few things. 1. Keep track of visited Nodes so we don’t visit the same one twice 2. Keep track of depth so we know our position in the word 3. Recursively search through the adjacent nodes

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

BOOL depthFirstSearch(Node * node, NSString * word, NSInteger depth, NSMutableSet * visitedNodes){

    unichar nodeLetter = [node.letter characterAtIndex:0];
    unichar wordLetter = [word characterAtIndex:depth];

    [visitedNodes addObject:node];

    if (nodeLetter == wordLetter){
        //if we have a match and have letters left keep searching
        //else we are at the end of the word so return YES
        if (depth < word.length - 1) {
            for (Node * adjacentNode in node.adjacentNodes){
                if ([visitedNodes containsObject:adjacentNode]) continue;
                BOOL found = depthFirstSearch(adjacentNode, word, depth + 1, visitedNodes);
                if (found) return found;
            }
        }
        else return YES;
    }

    [visitedNodes removeObject:node];
    return NO;
}

And thats it. Two simple functions achieve the objectives of the questions in 30 lines of code. For some interviewers this may be enough as this is considered to be the hard part of the question.

Going Further

There are several directions you could take this to make it more fully formed. For example, given a matrix of arrays could we build the graph? Also if were keeping the graph around it might make sense to make a graph object and make the search a method on a graph instance along with a graph generation method on the class. Ive tied it all together in a excerpt you can actually paste and run into an xcode command line app.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

#import <Foundation/Foundation.h>

@interface Node : NSObject
@property (nonatomic, strong) NSString * letter;
@property (nonatomic, strong) NSMutableSet * adjacentNodes;
@end

@implementation Node
-(NSMutableSet *)adjacentNodes{
    if(_adjacentNodes){
        return _adjacentNodes;
    }
    _adjacentNodes = [[NSMutableSet alloc] init];
    return _adjacentNodes;
}
@end


@interface Graph : NSObject
@property (nonatomic, strong) NSSet * nodes;
@property (nonatomic, strong) NSDictionary * lookupDictionary;

+(instancetype)graphForBoggleBoard:(NSArray *)board;

-(BOOL)searchForWord:(NSString *)word;
@end

@implementation Graph

+(instancetype)graphForBoggleBoard:(NSArray *)board{
    NSMutableSet * nodes = [[NSMutableSet alloc] init];
    NSMutableDictionary * dictionary = [NSMutableDictionary dictionary];

    NSMutableArray * nodeBoard = [[NSMutableArray alloc] initWithCapacity:board.count];
    for (NSArray * row in board){
        NSMutableArray * nodeRow = [[NSMutableArray alloc] initWithCapacity:row.count];
        for (NSString * letter in row){
            Node * node = [[Node alloc] init];
            node.letter = letter;

            [nodeRow addObject:node];
            [nodes addObject:node];
            if (dictionary[node.letter]){
                [dictionary[node.letter] addObject:node];
            }else{
                dictionary[node.letter] = @[node].mutableCopy;
            }
        }
        [nodeBoard addObject:nodeRow];
    }


    NSArray * previousRow = nil;
    for (NSInteger row = 0; row < nodeBoard.count; row++){
        NSArray * nodeRow = nodeBoard[row];
        for (NSInteger col = 0; col < nodeRow.count; col ++){
            Node * currentNode = nodeBoard[row][col];
            for (int i = col - 1; i <= col + 1; i++){
                if (i < 0 || i >= nodeRow.count)
                    continue;
                Node * node = previousRow[i];
                if (node){
                    [currentNode.adjacentNodes addObject:node];
                    [node.adjacentNodes addObject:currentNode];
                }
            }
            if (col > 0){
                Node * node = nodeBoard[row][col - 1];
                [currentNode.adjacentNodes addObject:node];
                [node.adjacentNodes addObject:currentNode];
            }
        }
        previousRow = nodeRow;
    }


    Graph * graph = [[Graph alloc] init];
    graph.lookupDictionary = dictionary;
    graph.nodes = nodes;
    return graph;
}

BOOL depthFirstSearch(Node * node, NSString * word, NSInteger depth, NSMutableSet * visitedNodes){

    unichar nodeLetter = [node.letter characterAtIndex:0];
    unichar wordLetter = [word characterAtIndex:depth];

    [visitedNodes addObject:node];

    if (nodeLetter == wordLetter){
        if (depth < word.length - 1) {
            for (Node * adjacentNode in node.adjacentNodes){
                if ([visitedNodes containsObject:adjacentNode]) continue;
                BOOL found = depthFirstSearch(adjacentNode, word, depth + 1, visitedNodes);
                if (found) return found;
            }
        }
        else return YES;
    }

    [visitedNodes removeObject:node];
    return NO;
}

-(BOOL)searchForWord:(NSString *)word{
    NSString * firstLetter = [NSString stringWithFormat:@"%c",[word characterAtIndex:0]];
    NSSet * firstNodes = self.lookupDictionary[firstLetter];
    for (Node * node in firstNodes){
        NSMutableSet * visitedNodes = [[NSMutableSet alloc] initWithCapacity:word.length];
        BOOL found = depthFirstSearch(node, word, 0, visitedNodes);
        if (found) return found;
    }

    return NO;
}
@end


int main(int argc, char *argv[]) {
    @autoreleasepool {
        NSArray * boggleBoard = @[
                                  @[@"a", @"b", @"c"],
                                  @[@"d", @"d", @"h"],
                                  @[@"e", @"i", @"u"]
                                  ];

        Graph * graph = [Graph graphForBoggleBoard:boggleBoard];
        NSLog (@"Word %@", [graph searchForWord:@"chuddd"] ? @"exists" : @"doesnt exist");
    }
    return 0;
}