How to create a new instance of an AppController in the NIB

Following the steps in Aaron Hillegass' SpeakLine tutorial in Chapter 5 of "Cocoa(R) Programming for Mac(R) OS X (3rd Edition)", I got lost on how to add the AppController to the nib. I found out this is what you need to do:

Assuming you've already added the "AppController.m" and "AppController.h" Objective C files to your project.

1. From Interface Builder, go to Tools > Library
2. Find NSObject under "Library - Cocoa - Objects & Controllers"
3. Drag that into the NIB window (i.e. - MainMenu.xib)
4. Rename the new NSObject to "AppController"
5. With the "AppController" object highlighted, go to Tools > Identity Inspector, drill down on the "Class" field and select "AppController"
6. Your AppController class is now added to the nib

Accessor Methods: "Retain, then Release" methodology

From "Cocoa(R) Programming for Mac(R) OS X (3rd Edition)" by Aaron Hillegass

If you have a nonpointer type, the accessor methods are quite simple. For example, if your class has an instance variable called foo of type int, you would create the following accessor methods:

- (int)foo
{
return foo;
}

-(void)setFoo:(int)x
{
foo = x;
}

MATTERS BECOME MORE COMPLICATED IF FOO IS A POINTER TO AN OBJECT. In the "setter" method, you need to make sure that the new value is retained and the old value released, as shown below:

-(void)setFoo:(NSCalendarDate *)x
{
[x retain];
[foo release];
foo = x;
}

I installed XCode but cannot find the executable. Where does it get installed?

Once you download and install XCode, the executable can be found here:

Macintosh HD > Developer > Applications > XCode

Debugging "objc[17695]: FREED(id): message release sent to freed object=0x1073d0"

Here's a good article on how to troubleshoot these kinds of errors:
http://www.cocoadev.com/index.pl?DebuggingAutorelease

Taken from the article:

One of the most opaque bugs I've had to deal with in Cocoa is leaving a released object in the autorelease pool, causing an EXC_BAD_ACCESS in NSPopAutoreleasePool?(). When this happens, it's pretty much impossible to tell what the doubly-released object was and where it was instantiated.

Fear no more! Using Cocoa's NSZombie? debugging class and the command-line malloc_history tool, we can nail this bug in a pinch.

Suppose you have the following (obviously incorrect) code:

  NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
 NSData* data = [NSData dataWithBytes:"asklaskdxjgr" length:12];

 [data release];
 [pool release];

The dataWithBytes: method sends an autorelease message to the created object, so we don't need to release it ourselves. When the autorelease pool is tossed the freed data object gets another release message, our app crashes, and we have no idea why.

The dataWithBytes: method sends an autorelease message to the created object, so we don't need to release it ourselves. When the autorelease pool is tossed the freed data object gets another release message, our app crashes, and we have no idea why.

Here's what we do:

Click on the "Targets" tab, open "Executables" and select the app (In XCode 2.0, double-click the executable in the file tree and select the arguments tab to enter environment variables). In the executable settings, add the following environment variables and set their values to "YES" (without the quotes):

  NSDebugEnabled
NSZombieEnabled
MallocStackLogging

You may also want the following environment variable set to YES:

  MallocStackLoggingNoCompact

With NSZombieEnabled, Cocoa sets an object's isa pointer to the NSZombie? class when its retain count drops to zero instead of deallocating it. Then when you send a message to an NSZombie? object (i.e., you're accessing freed data), it raises an exception and tells you where the object lives:

  2003-03-18 13:01:38.644 autoreleasebug[3939] *** *** Selector 'release'
sent to dealloced instance 0xa4e10 of class NSConcreteData.

Since you have MallocStackLogging turned on, you can now run "malloc_history

" to see the stack trace when the object was allocated:

  [dave@host193 Frameworks]$ malloc_history 3939 0xa4e10

Call [2] [arg=32]: thread_a0000dec |0x1000 | start | _start | main |
+[NSData dataWithBytes:length:] | NSAllocateObject | object_getIndexedIvars |
malloc_zone_calloc 

if you run under gdb, you may enter:

 (gdb) shell malloc_history 3939 0xa4e10

And there it is: the double-released object was allocated with [NSData dataWithBytes:length:] in the function main()!

I love you, Cocoa!

Currently Reading "Cocoa(R) Programming for Mac(R) OS X (3rd Edition)" by Aaron Hillegass

This Purchase: $26.97 | Running Total: $2981.72

Before moving on. I think I really need to learn Objective C

So far, I've encountered enough code in Objective C in the Apple iPhone documentation to say that I'm lost Being new to the iPhone, with no prior experience in Cocoa nor Objective C, I found myself getting very little out of the articles I've read so far from Apple's dev center. I thought since I already knew how to program in Java, C, C++ and PHP that I would have enough of a programming background to learn Objective C as I go along but I was wrong. I found Objective C to be a language unlike any other I've ever seen before.

Today, I made the decision to spend some more time to focus on learning Objective C. Hopefully after a weeks time I'll have a stronger grasp of the language and then get back on track to create this iPhone application.

As a first step towards becoming more proficient in Objective C, I went to the bookstore today and picked up a book called "Cocoa Programming for Mac OS X". Chapter 3 is about Objective C and I found it to be a very well written and easy to digest introduction to the Objective C programming language. The introduction provided me with answers to a lot of the questions I had about the code snip-its in previous articles, such as why we use brackets so much [ ], why functions begin with -, why we don't explicitly declare private, protected and public classes and why Objective C makes such liberal use of the '@' character, to name a few.

Now, not only do I better understand what is going on, but I am beginning to see a benefit to doing things in Objective C. Check out Chatper 3 for yourself and you'll be surprised at how fast you will learn. The book is written by Aaron Hillegass and I highly recommend it:

I'll be spending the next week reading this book and I'll be going through this Objective C tutorial published by Apple.

Apple Objective-C Tutorial PDF

Memory Management: alloc vs. convenience constructor vs. accessor method. What is the difference and which is preferred?

The following simple examples illustrate the contrast between creating a new object using alloc, using a convenience constructor, and using an accessor method.

The first example creates a new string object using alloc: It must therefore be released.

- (void)printHello {

NSString *string;

string = [[NSString alloc] initWithString:@"Hello"];

NSLog(string);

[string release];

}

The second example creates a new string object using a convenience constructor: There is no additional work to do.

- (void)printHello {

NSString *string;

string = [NSString stringWithFormat:@"Hello"];

NSLog(string);

}

The third example retrieves a string object using an accessor method: As with the convenience constructor, there is no additional work to do.

- (void)printWindowTitle {

NSString *string;

string = [myWindow title];

NSLog(string);

} According to Apple, using accessor methods is the preferred way to go. "Sometimes it might seem tedious or pedantic, but if you use accessor methods consistently the chances of having problems with memory management decrease considerably. If you are using retain and release on instance variables throughout your code, you are almost certainly doing the wrong thing." http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html