Several native applications on the iPhone use application badges as an indicator of new messages, think email and SMS. Creating badges is quite straightforward and is nothing more than a method call, passing in the desired number to display.
This is the third and final post in a series reviewing the book Cocoa Programming, by Aaron Hillegass. Here are links to the first and second parts of this review.
In this post I’ll review a few highlights of the book as well as offer a few suggestions (from my perspective) for improvement should another edition be forthcoming. Let’s begin with the highlights.
This post is the second in a series reviewing the book Cocoa Programming, by Aaron Hillegass. This part of the review is dedicated to a closer look at the code examples.
Starting from Chapter 2, the book dives into building relevant code examples. Working with Xcode and Interface Builder, you’ll quickly become familiar with the interface and interaction among both tools. There is even a short segue into the basics of debugging in Chapter 3.
This post is the first in a series reviewing the book Cocoa Programming, by Aaron Hillegass. Even if you plan to write applications solely for the iPhone, you’ll find that a good Cocoa reference is essential as you get started. Read on to learn more about Aaron’s Cocoa book.
Let me begin by saying, Aaron knows Cocoa. As a previous employee of NeXT which merged with Apple, Aaron has extensive experience teaching developers, including many Apple Engineers, how to write applications for Mac OS X.
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:
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.