Stupid Objective-C Mistake #1

While laying out my screen, I keep objects handy in a couple of NSArrays. Typically, I start out coding all the layouting code and retouch it once I see what's rendered on screen. Many times, objects that I try to add to my layout just do not appear - because I failed to initialize my arrays!

Since in Objective-C, a message to a nil-variable just returns nil and moves on, you dont't have any indication that something might not go according to plan. Therefore this little note to self:

First thing to do if things do not appear on screen, check your arrays initializations, stupid!

Note to Self on Void Pointers and CallFuncND

This is no news to anyone except for people who have never been exposed to void pointers (void*) before. Coming from a Java-background, I never had the opportunity (or dare I say hassle) to deal with pointers, obtaining memory addresses and de-referencing those. Whenever I was confronted with C / C++, I tried my best not to dive too deep into that matter.

Now in Objective C, I finally wanted to get rid of a compiler warning I was getting because I was dealing with void* as a data type. Basically, void* is a pointer to some data in memory of which the type is unknown to the compiler. Therefore, any address to some data in memory can be stuffed into a variable of type void*. Both of the following is valid:

void* data;
int i = 5;
float f = 6.5;

data = &i; // first assignment: works
data = &f; // second assignment: works, too

Now to get back to the data you stuffed inside, you cannot just de-reference it just like that. You need to cast it to the proper pointer type of the data that is stored at the particular address you're pointing to. In other words, you'd have to do the following (continuing the code above):

int* iPtr = (int*) data; // if data contains &i
float* fPtr = (float*) data; // if data contains &f

Since cocos2d uses void* as the data type to piggy-back any kind of user data within a CallFuncND action, I at least had to get that straight!

Properties vs Instance variables

So being able to work with properties in Objective-C is very nice but there are subtle things to keep in mind when using them.

I just came across a problem which cost me about 30 mins of my time. In one of my methods I was (supposedly) assigning an object to one of my properties. The property was marked with retain so that it was supposed to be retained unless re-assigned or the owning object is dealloc'ed. Unfortunately, in a different part of the code, accessing that very property threw an exception.

Turns out that I hadn't yet mastered the subtle difference between properties and instance variable. Assume the following code sample:

@interface Foo : NSObject {
NSString* bar;
}
@property (retain) NSString* bar;
- (void) test;
@end

@implementation Foo {
@synthesize bar;

- (void) test {
NSString* str = @"Test";

// this assignment does not use the synthesized setter
// but accesses the instance variable directly
bar = str;

// same here
self->bar = str;

// only this way of accessing uses the setter and thus
// retains the object reference
self.bar = str;
}
}

First of all I did not know about the arrow-way of accessing instance variables, secondly I thought access as displayed in the first assignment would use the setter method.

Hope this helps in case you're ever going to scratch your head because of this!

+ (void) load

I just happened run into one of those things that must happen to you if you just go out there and try to learn a new programming language from scratch without using any tutorial books.

Just for the sake of getting started with some Objective-C coding, I'm implementing some 2D animation functionality based on an animation tool coded in Java. Trying to load the files its creates using Objective-C, I implemented a method called load in one of my classes. Things got properly loaded - but, to my surprise, I also saw some error messages in the console hinting at leaking memory. An autorelease-pool was set up in my main class so I was wondering what could possibly have gone wrong.

Turns out + (void) load is method defined in NSObject class which is used for initializing objects. It got called even before my autorelease-pool was initialized, thus the leaking. Keep that in mind if you see error messages saying "No autorelease pool in place" or "Just leaking" even though an autorelease-pool is set up in your main class.