With this theoretical knowledge in place, open BrokenCrunch and let’s get started. After loading our sample application, select Build > Build and Debug. You’ll notice that the application fails to launch, and the compiler has generated a number of errors. To view the results of the attempted compilation, select Build > Build Results.
Selecting the errors listed will take you directly to the line of code where the error is being reported. One important thing to keep in mind, however, is that the number of errors being reported by the compiler and the line numbers of those errors should be thought of as the “best guess” of what’s wrong with your application, not a conclusive pronouncement.
In fact, one simple syntax error can result in multiple errors being reported by the compiler that are seemingly unrelated to the problem. As an example, take a look at the “Expected bracket before ‘setImage’” error line. If you examine the line in question, you should find that the syntax is perfect. As it turns out, the problem here isn’t on the line reported, but the line just above it. Do you see the problem?
The NSLog() statement wasn’t terminated with a semicolon. This means that the compiler doesn’t know that you intended to end the line after the last parenthesis, and is viewing everything from NSLog to the final closing bracket and semi-colon after UIControlStateNormal as one statement.
Add the semicolon to complete the NSLog statement:
- NSLog(@"In crunchCookie");
Save the source file, and click “Build and Debug” again. Two of the three errors originally displayed should now be resolved.
Next, select the “No declaration of property” error. As you can see, this error is reporting that the property we are attempting to synthesize doesn’t exist. To verify this, open the FortuneCrunchViewController.h file where the property should have been declared. If you examine line 17, the syntax is correct, but we do have a mismatch between the property we have declared and the one we are attempting to synthesize. Objective-C is a case-sensitive language, meaning that the ‘C’ in cookie must be capitalized to match the property we are attempting to synthesize. Update the property declaration in the header file to read:
- @property(nonatomic, retain) IBOutlet *fortuneCookieButton;
Save the source file and build and debug once again. This time, rather than opening the build results fromBuild > Build and Debug, simply click the error icon in the bottom right corner of Xcode.
One step forward, four steps back. The error regarding the synthesize property line is gone, but we have an entirely new list of errors. What happened?
This is a good time to take notice of the different phases being shown in the Build Results window:
Notice that we have one warning underneath the “Compile” section of the build results output. This is the same section that our previous errors were being reported in. Now that the previous three errors have been resolved, we have been able to progress from the compile phase to the linking phase of our application build, and all of the new errors are linking errors. When you encounter a linking error, it’s typically because you are trying to use functions from a framework that you haven’t actually included in your application. In this case, the Build Results are referencing a function called _UIApplicationMain in the main.o file. Main.o is the compiled, machine code version of main.m. Let’s take a look at the source code in that file. On line 13 you can see a function call to UIApplicationMain:
- int retVal = UIApplicationMain(argc, argv, nil, nil);
UIApplicationMain is a central function to every iOS application, but how can you find out more about it and figure out what framework it is included within? Fortunately, the iOS SDK comes with some great documentation. If you hold down the option (or alt) button and double-click the function name, you will launch an abstract from the official iOS SDK documentation discussing this function. Click the “book” icon in the top right to view the full documentation available. You can see that doing so launched the function reference documentation for the UIKit framework. Bingo, we have our missing framework. However, before we add the framework to the project, let’s examine another method that you could have used for determining the origin of UIApplicationMain.
Close the documentation window. Now, hold down the command button and double-click theUIApplicationMain function. You are now looking at the source of UIApplication.h, the header declaration file that contains the UIApplicationMain function declaration. If you scroll to the top of the window, you will see that this file imports multiple other UIKit headers, and that the comment at the top includes the “UIKit” framework name.
Let’s move on to resolving these linking errors by including the UIKit framework. To do so, right click or control click on the Frameworks folder in the Groups & Files pane, and select add > existing frameworks. Find the UIKit framework and click “Add.” To test our work, select Build and Debug again.
As you can see, the simulator launched successfully and we are able to view our application. This means that we have resolved all of the compile-time errors in our application.
Go ahead and click the fortune cookie. . .as you can see, clicking the cookie results in a run-time error and the application has crashed. The message displayed in the bottom left of the Xcode screen isn’t very helpful, so let’s take a closer look by opening up the console.
The console displays both a call stack of what was occurring in our program execution at the time of the crash, as well as a more detaild explanation: “Terminating app due to uncaught exception. . .FortuneCrunchViewController cookieCruncher: unrecognized selector sent to instance.” This message means that our button is calling the wrong selector for the event that we fired by clicking the cookie. Since the interface for FortuneCrunch was built in Interface Builder, let’s open the Interface Builder XIB file for “FortuneCrunchViewController” to take a closer look.
Select the cookie button and control click or right click to view a list of connected actions:
You can see that the Touch Up Inside event is referencing a target that doesn’t exist, indicated by the yellow text. Remove the non-existent “cookieCruncher” target and reconnect touchUpInside to File’s Owner by selecting the “crunchCookie” target that appears in the drop down. Save your work in Interface Builder, switch back to Xcode, and relaunch the application.
Clicking the fortune cookie again results in a run-time error. This time, the console message isn’t so helpful, it just displays “EXC_BAD_ACCESS”.
Take another look at the build results by selecting Build > Build Results. Did you notice the warning earlier? Compiler warnings are often an indication of a potential run-time error, but because there is nothing incorrect with the actual syntax of the line the warning is issued for, the compiler is still able to build the application successfully. Of course, there are times when a compiler warning is a “false flag” and will not result in a run-time error, but upwards of 95% of the time, if the compiler has issued a warning you are doing something wrong.
Click on the warning to jump to the line in your source code where it occurred.
The warning is referring to incompatible pointer types. Do you see the problem? The imageNamed method expects an NSString object, but this line of code is supplying the method with a literal C style string. Add in the “@” symbol to make this an Objective-C string:
- [fortuneCookieButton setImage:[UIImage imageNamed:@"cookie-closed.png"] forState:UIControlStateNormal];
Save your progress and run the application again.
This time, when you click the fortune cookie you encounter a logical error: the application doesn’t crash and the “Happy iPhone Hacking” label appears as expected, but the background image remains as the closed cookie.
To fix this, let’s take a look at the function responsible for the transition: (IBAction)crunchCookie. Line 19 is responsible for changing the background image and you can see that it is setting the new background image to “cookie-closed.png”. If you take a look at cookie-closed in the Resources folder, you’ll see that this is in fact the same image displayed when the app first loads. We need to change that line to transition to “cookie-crunched.png”:
- [fortuneCookieButton setImage:[UIImage imageNamed:@"cookie-crunched.png"] forState:UIControlStateNormal];
Build and run the application again. . .and now tapping the cookie results in the expected background image with the label displayed properly.
Congratulations! You’ve just walked through the process of fixing compile-time errors, run-time errors, and logical errors in an application. All the while, we have barely tapped into the powerful debugging tools available to you with Xcode.
To continue our exploration of the more advanced debugging tools available, let’s try to extend the FortuneCrunch app to make it a bit more interesting. Rather than display the static string “Happy iPhone Hacking!” every time the cookie is crunched, let’s build an array of multiple NSString values that could be displayed.
Switch back to Xcode and open the FortuneCrunchViewController.h file. Add the following data member:
This array will be used to hold our random fortune strings.
Now, add the following method signature:
- -(NSString *)generateRandomFortune;
This line will declare a new method in our class that will be used to select a random fortune from our fortunes array.
Next, switch to FortuneCrunchViewController.m. Since this class will be initiated from our XIB file, we need to override the initWithCoder method and allocate the array we declared in the .h file, initializing it with some new fortunes:
- -(id)initWithCoder:aDecoder
- {
- self = [super initWithCoder:aDecoder];
- if(self)
- {
- fortunes = [[NSArray alloc] initWithObjects:
- @”He who throws dirt loses ground.”,
- @”A closed mouth gathers no feet.”,
- @”Help! I am a prisoner in a bakery!”, nil];
- }
- return self;
- }
Now that we’ve created a new NSArray, don’t forget to release it in the dealloc method:
- -(void)dealloc
- {
- [fortunes release];
Let’s move on to coding the generateRandomFortune function:
- -(NSString *)generateRandomFortune
- {
- int chosen_index = arc4random() % 3 * 10;
-
- return [fortunes objectAtIndex:chosen_index];
- }
These lines simply generate a new, random index number that we will use to return the corresponding fortune string.
Finally, modify the crunchCookie method to use one of our random fortunes rather than the static text “Happy iPhone Hacking!”:
- fortuneLabel.text = [self generateRandomFortune];
Build and run the application after saving these changes. If you click the cookie, you will create a run-time error. To figure out why this is happening, we’re going to use the Xcode debugger and custom breakpoints.
A breakpoint is a flag that signals to your application that program execution should “pause” when the line with the breakpoint is reached. Running your application in “Build and Debug mode” allows you to use breakpoints. To set a breakpoint, simply click in the editor “gutter” on the line you would like to trigger a breakpoint. To figure out what’s happening in our application, we’re going to set our breakpoint on theNSLog line, just after the crunchCookie method is called:
Build and debug the application with this new breakpoint in place.
After the application loads, click the cookie. If you look in the bottom left of Xcode, you’ll see the status message “Stopped at breakpoint 1”. This means the debugger has successfully stopped program execution at the breakpoint you set. You’ll also notice that a red arrow indicates the current line of execution where the debugger has “paused” the program.
So, what can you do with the debugger? More than can be covered in a single tutorial. However, there are three fundamental actions you can take at this point: Step over, step into, and step out. All of these options are available to you from the in-code debugger menu bar.
If you press the “step over” button on the in-code debugger menu, you’ll notice that program execution continues to the next line. “Step over” will simply continue execution one line at a time within the current method, but it won’t follow your code execution if it forks to another method. If you want to actually follow the code execution into other method calls in your code, you will need to use the “step into” button.
As you can see, step into has actually taken us into the generateRandomFortune method, which is exactly what we want. Click “Step over” again to see what happens when arc4random() is called. Wouldn’t it be nice if we knew what the chosen_index variable has just been set to? Fortunately, we can! One of the best features of using the debugger is the ability to simply mouse over variables to quickly see their value.
Clearly, the chosen_index value is much larger than the length of our array. Unlike in some other programming languages, the randomization function we are using will return an integer, so there is no need to convert from a decimal to an integer by multiplying the value by 10. Update the line to read:
- int chosen_index = arc4random() % 3;
We’re done making modifications to this function, so use the “Step Out” button to exit this sub-function and return to crunchCookie. Note that even though we didn’t see it, the rest of the function executed as normal.
Finally, take note of the “Activate / Deactivate” breakpoint button and the “Continue Execution” button on the in-code debugger menu bar. “Continue Execution” will simply allow program execution to continue as normal. You can think of it as the “unpause” button. Go ahead and press this now.
Before we move on to turning off breakpoints, there is one more issue to tackle: what you have just experienced is called the “in-code debugger”. It’s very powerful, but there are also two other debugging modes available to you: the full debugger window and the mini-debugger perspective.
To access the full debugger window, click the “debugging” icon on the in-code debugger menubar. This window has significantly more information than the in-code debugger. On the left you have a stack-trace displaying the context of program execution (you also have the ability to select from any of the currently spawned threads). To the right, you can see a quick display of the various variables currently held in memory. Selecting a different call-stack signature will change your view in the Debugger. You can change the Debugger window layout by going to Run > Debugger Display.
Finally, the mini-debugger is yet another debugging perspective available to you. I rarely use this perspective, but it is available to you from Run > Mini-Debugger.
Since we just resolved the error introduced in our random fortune code, we no longer need the debugger to be on. Toggle off breakpoints. However, before we build the application again, let’s adjust the font size of our fortune label.
Open Interface Builder, select the label and change the font in the Inspector to Arial Black, 9 point, and then select the “Adjust to fit” box and change the minimum font size to 6 point. Now, build and run our project again.
Voila! Our application now functions as we intended.
Sumber : http://mobile.tutsplus.com/tutorials/iphone/xcode-debugging_iphone-sdk/
