Cocoa

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.

You can read the rest of the tip on the iPhone Developer Tips blog.

Lastnight was the second meeting for CocoaHeads in Minnesota .

The meeting was all about Objective-C. Bob McCune , the organizer of the event, gave a talk that covered Objective-C from beginning to end. One of the most intriguing aspects (at least from my perspective) was how the group would segue into a discussion on a topic. What was quite helpful was insight from those in the group who had significant experience working with Cocoa and Objective-C.

Bob did an excellent job, covering a great deal of ground, and wrapped up with an demo of a calculator application that tied together many of the concepts. If you are new to working with protocols, I highly recommend you download and give the application a look. The example shows how you can define and implement a protocol – no better way to learn a concept than to see it in code (I’ll add a link to the code once it is posted on the MN CocoaHeads site).

Many thanks to Bob McCune for starting MN CocoaHeads , Synergy Information Systems for making the space available, and Vladan Pulec (Synergy) for adding a link to this blog from the CocoaHeads MN website.

If you live in Minnesota, are within reasonable driving distance to Bloomington (or even if not) and are interested in developing applications for the Mac/iPhone, join us on August 14th (the second Thursday of every month) for our next meeting.