How to Use NSLog to Debug CGRect and CGPoint

CGPoint and CGRect are structures (versus objects) and therefore the old NSLog standby %@ will not work as expected.

Here is how each structure is defined:

struct CGPoint {
   CGFloat x;
   CGFloat y;
};
typedef struct CGPoint CGPoint;
 
struct CGRect {
   CGPoint origin;
   CGSize size;
};
typedef struct CGRect CGRect;

If you attempt NSLog to use the traditional ‘print object’ notation such as this:

// Print point structure using NSLog
CGPoint cgPoint = CGPointMake(1, 11);
NSLog(@"%@", cgPoint);

the compiler will generate a warning: Format specifies type ‘id’ but the argument has type ‘CGPoint’ (aka ‘struct CGPoint’)

Good news is, this is easy to fix:

Continue reading

Display Debug Information In A Popup Window (UIAlertView)

I previously shared the code I use to replace NSLog, as I really don’t care for the date/time stamp that NSLog outputs to the console.

Every now and again rather than looking at the console, it can be helpful to have a popup (UIAlertView) with the same information that one would include in NSLog. Let’s see how to accomplish this…

Assume you have the following code:

NSString *str = @"iOS Developer Tips";
int x = 101;
 
NSLog(@"str: %@ x: %d", str, x);

The output will look as follows:

2013-04-07 23:28:42.404 Sandbox[18767:c07] str: iOS Developer Tips x: 101
Continue reading

Filename and Line Number with NSLog: Part II

In the previous post I demonstrated a simple debug class that I wrote to wrap some additional code around NSLog. The code allows for displaying additional information beyond the date/time stamp and process ID that NSLog outputs, specifically, the filename which calls the debug routine, and the line number where the call was invoked. I also added a few additional configuration options including an option to disable all debug messages.

The figure below shows the debug routine called from within two separate source files. Notice the filename and line number references:
Continue reading

Filename and Line Number with NSLog: Part I

Coming from a C development background, long before the days of integrated debuggers, printf() was the primary tool for tracking down bugs. Building on that, NSLog is no doubt helpful. However, as the amount of code in a project grows, I often find that another reference point in the output would be helpful, namely, the filename and line number where the NSLog calls originate.

This is a two part series on creating a new class that wraps NSLog to add several additional debugging features including output of the filename/path, line number information and the option to turn debug messages off/on.
Continue reading