May 212009
 

I thought that, for the most part, I was done with memory management after moving on from C/C++ to Java. But we all know that was not to be, so I’ve created this quick reference sheet for my own reference that some of you may find useful.

Pitfall 1: The order matters
Assume we have a setter method in some class.

-(void) setText:(NSString *)newValue
{
   if (newValue != text)
   {
      [newValue retain];
      [text release];
      text = newValue;
   }
}

The NSString that is passed into setText may be another NSString. So the value that is passed in must be retained, because we can’t have the memory freed until we are done with the class. We release text because it is being repaced with newValue.

Note that it is wrong the write the code above as

-(void) setText:(NSString *)newValue
{
      [text release];
      [newValue retain];
      text = newValue;
}

This is a due to a somewhat subtle case when text and newValue points to the same instance of NSString. By releasing text, newValue will also be released.

Pitfall 2: Using the dot (‘.’) notation incorrectly

self.text = newText

is actually a shorthand form of

[self setText: newText]

Thus, it will retain newText, increasing the reference count. Do not confuse it with how it works in a language like Java.

this.text = newText

is different from

self.text = newText

Because the first is a direct assignment and the second is actually a message call.

Pitfall 3: Not following the fundamental rules of reference counting
The fundamental rules are:
1. If you allocate, create or copy it, you need to release it.
2. If you retain it, you need to release it.

Consider the following snippet of code

SomeObject *newObject = [[SomeObject alloc] init];
self.object = newObject;
[newObject release];

newObject needs to be released to balance the retains. The first retain is in the alloc call, and the second retain is in the setObject (aka self.object = newObject) message.

Also, if you write something like this

self.object = [[SomeObject alloc] init];

the retain count will be at 2 because it is retained once for the alloc and one more time for the setObject message.

If you’d like to read more about memory management, here is another post that I wrote about the topic (I also talk about NSAutoReleasePool a bit here).

This wasn’t a comprehensive overview of memory management, but I hope it was somewhat helpful.

 Posted by at 8:50 am
May 072009
 

I don’t know what has been going on (actually, I do), but we have been seeing a statistically significant increase in the sales of iHappyBirthday. It wasn’t too long ago that we noticed that our application would not appear in the search results if the search terms were “happy birthday”, though it was still search-able with the term “birthday”. It was odd because it has always been search-able by “happy birthday.”

We emailed Apple about it, and the response we got back was pure hilarity.

Search results are working as expected at this time. App Store search results are based on several factors determined by Apple-confidential algorithms.

I’m not sure what this super secret “Apple-confidential algorithms” were that made it unsearchable by “happy birthday”, but it at least it did make us laugh. It was most likely a canned response because search was actually broken.

Anyways, we didn’t realize how important it was for our application to be search-able by “happy birthday”, because as soon as search was fixed, our sales have doubled (albeit from a small number, but welcome none the less!).

 Posted by at 1:29 pm