Cocoa Swirl

Owning Up – Release, Retain, and Object Ownership

Rob Bajorek — Tue, 21 Jul 2009 16:58:33 +0000

Ever used the NSString class? If you’re reading this, you probably have. Let’s look at a couple of ways to create NSStrings with the …WithFormat: methods.

- (id)initWithFormat:(NSString *)format …
Returns an NSString object initialized by using a given format string as a template into which the remaining argument values are substituted.

+ (id)stringWithFormat:(NSString *)format, …
Returns a string created by using a given format string as a template into which the remaining argument values are substituted.

Hmm, they both sound about the same, take the same arguments, and return an NSString object. Apple made these two functions for a reason, so what’s the difference?

There are semantic differences in usage, but the real difference I’m talking about is who owns the NSString object.

Object Ownership in Objective-C

From the object’s perspective, what does it mean to be owned? According to Apple’s Memory Management Guide, an object exists as long as it has at least one owner. There are no restrictions on how many owners an object has; it can have none or a hundred. An owner relinquishes ownership by sending their object a release or autorelease message. When the last owner has given up ownership, the application will dispose of the object automatically.

How do you know if an object is yours?

If you create an object with alloc, new, or copy, it’s yours.
If you retain an object, it’s yours.
Everything else is not yours.

That’s it.

What does that mean? The main point of object ownership is you choose to own an object because you don’t want it deallocated. If an object is not yours and you want to keep it around, you must retain it and make it yours. Otherwise, the system may take it away from you.

We’re also talking about memory management. You must clean up after yourself. If an object is yours and you’re done with it, you must release or autorelease it. If you don’t, you create a leak: allocated memory that cannot be freed because you’ve lost the reference to it. Leaks cause memory problems, and if this is an iPhone app then Apple may reject it until you fix the mess.

An example

Here’s a snippet that demonstrates different ownership situations.

/* Create some strings */
int count = 1;

NSString *string1 = [[NSString alloc] initWithFormat:@"This is string %d. It's mine, so I need to release it when I'm done.", count];
count++;

NSString *string2 = [NSString stringWithFormat:@"This is string %d. It is not mine, so I won't release it.", count];
count++;

NSString *string3 = [[NSString stringWithFormat:@"This is string %d. We are retaining it, so we must release it later.", count] retain];
count++;

... // code using the strings snipped

/* Done with the strings, get rid of them */
[string1 release];     // Released and gone
// [string2 release];  // string2 is not ours, so releasing it is an error
[string3 autorelease]; // Still here until NSAutoReleasePool is drained

The string1 object is created with alloc and initialized by initWithFormat:. Checking the rules, alloc is one of our special keywords, so string1 is ours. We need to release it, and in fact we do so. No problem.

Our string2 object is created with the NSString factory method stringWithFormat:. The method name doesn’t use the ownership keywords, so string2 is not ours. It will be autoreleased. In fact, if you release it…

Program received signal: “EXC_BAD_ACCESS”.

Oops! Don’t do that!

Lastly, string3 is an autoreleased string like string2, but this time we retained it. Using retain takes ownership of it, so string3 is ours. We need to release it when we’re finished with it. This time though, we chose to autorelease it. We don’t own it anymore, but it’s still around.

Release vs. Autorelease

As we’ve seen, there are two ways to disown an object: release and autorelease. What’s the difference?

If you use release, the effect is immediate. If you were the last owner, that object is gone and memory is freed.

CSWidget *widget = [[CSWidget alloc] init];  // New widget, owned by me
[widget shake];
[widget twirl];
[widget release];  // widget is gone

Usually this is fine, but that may not be what you want.

Take “(NSString *)stringWithFormat: (NSString *)format, …” . How can stringWithFormat: disown its returned object without losing it? By using autorelease.

+ (CSWidget *) widget {
  CSWidget *widget = [[CSWidget alloc] init];  // New widget, owned by me
  [widget autorelease];  // Not owned by me anymore, but still exists
  return widget;
}

We created a widget object and disowned it, but its release is delayed until the current NSAutoReleasePool is drained. That is a subject for another post, but simply, the pool is drained after every pass of the main event loop.

Short version: release = immediate, autorelease = delayed.

For the Mac folks

On Mac you can use garbage collection now, so should you put in retain and release messages if they are just no-ops? Generally no, but with one exception. If there’s a chance you’ll port your Mac code to iPhone, I would consider using reference-count rules. If you don’t, you’ll have to go through the code again and fix it up to work on iPhone.

More information

I recommend reading the Memory Management Programming Guide for Cocoa for a complete explanation of object ownership and memory management.

Review

Know the ownership keywords (alloc, new, copy, retain)
Retain objects you want to keep
Don’t release objects that aren’t yours
Use release when you don’t care if an object is deallocated immediately
Use autorelease to give up ownership but delay an object’s release

Good luck!

WWDC 2009 Videos Released

Rob Bajorek — Mon, 29 Jun 2009 23:28:44 +0000

For all of you WWDC attendees and Premier ADC members, good news! The WWDC 2009 videos are now available!

I heard rumors that this was going to take a couple of months, so I’m very happy that they are already on iTunes U.

Now if you’ll excuse me, I’m going to catch the OpenCL and Grand Central Dispatch sessions I missed the first time!

Click here for ADC on iTunes and the videos. (WWDC 2009 attendees and Premier ADC members only.)

Five Points From Attending WWDC 2009

Rob Bajorek — Thu, 18 Jun 2009 23:02:07 +0000

I’m back home from Apple’s Worldwide Developers Conference in San Francisco. It was my first time, and a fun, productive experience. There are some great posts about WWDC that I read before I went, but here are some more things I noticed:

#1 — If you don’t live for the keynote, just fly in Monday morning

I heard stories about crazy lines for the keynote, so my friend and I decided to just show up around 9:30. When we arrived, they weren’t letting people in yet and the line wrapped around the whole convention center. Forget that! We went to a coffee shop, followed a live Twitter feed, and went back around 10:20. Much better, walked into the overflow room and saw almost all of the show. Next year I’m coming to SF on Monday morning and joining the overflow crowd again.

#2 — It’s easy to make friends…

… but most people there aren’t going to strike up a conversation. It’s up to you to make the first move. It’s ok! Mac geeks are friendly and you can meet some interesting people. (However, I didn’t have anyone come up to me who wasn’t trying to sell me something, so please don’t be that person.)

#3 — Don’t pass out business cards to random people

This concept is Business 101 in my opinion, but I don’t offer my business card to someone unless we’ve established a relationship. Handing out cards to people walking by is just wasting money and generating ill will. A few guys were doing this inside Moscone West; their cards went right in the trash.

#4 — Know where to find power outlets

If you’re at WWDC, you probably have a laptop. I was worried about keeping charged throughout the day, but it wasn’t a problem at all!

The session rooms had power strips like the one pictured mixed in with the seats. They weren’t always in every row, so sometimes you would plug into the row behind. When you’re roaming Moscone West, there were a number of tables with power strips, as well. Also, in the hallways there were small clusters of power outlets in the walls that many people overlooked.

#5 — Almost every seat is a good one

The display screens were very large and the acoustics good in every room. Unless you want to see the speakers up close, you can sit pretty much anywhere.

For the heck of it, I did sit in the front row for one session. I ended up with a sore neck from trying to see the screen. Just sit in the middle.

Anything else?

Feel free to post your own comments and accumulated wisdom from WWDC!

Example project for the Cheetah3D header converter

Rob Bajorek — Tue, 09 Jun 2009 01:08:51 +0000

Some folks have asked me for examples of how my Cheetah3D -> iPhone header converter works. To help you out, I’m posting an Xcode project that I’m using to test the converter.

You can get it here: C3DConverterTest.tgz

This project renders four different shapes generated in Cheetah3D. It’s pretty simple; a lot of the code is from the Xcode’s standard OpenGL ES project template. I’ve added lighting to show that the normals work properly, though.

Some notable files:

4 shapes.jas — the Cheetah3D project
4 shapes.h — the header file exported from Cheetah3D. You can run this through the converter yourself if you like.
4 shapes_iphone.h — the header file made by my converter
pure_colors.jpg — A simple texture. Replace this with your own for a different look.

I hope this helps! Let me know if you have questions or comments.

Version 2.0.1 of Cheetah3D header file converter for iPhone released

Rob Bajorek — Fri, 05 Jun 2009 01:56:49 +0000

I’ve updated the Cheetah3D -> iPhone header file converter to version 2.0.1. This version corrects object names from Cheetah3D that aren’t valid in Objective-C. (Example: “Box.1″ is renamed to “Box_1″). Thanks to reader Scott for pointing out the problem and a solution.

Download version 2.0.1 here: c3d_to_iphone.pl (zipped)

Please comment or contact me with any feedback!

iPhone OpenGL Speed Tip – Turn Off Thumb Instructions

Rob Bajorek — Thu, 21 May 2009 00:09:47 +0000

Want to boost your iPhone OpenGL app’s framerate with one checkbox? It’s easy; turn off Thumb instructions.

What are Thumb instructions?

The iPhone uses the ARM 1176JZ processor, and Thumb instructions are 16-bit versions of common 32-bit ARM instructions. By default, your Xcode project will compile with Thumb instructions.

Why use Thumb instructions?

On embedded systems like the iPhone (or any system, really, but here especially), you have to think about the space your app uses. Smaller instructions mean smaller code in memory and on disk. That’s a good thing! However, there’s a trade-off: performance.

According to Apple, the cost comes from floating-point operations. Ripping out the GLfloats from your app isn’t the way to go, so let’s learn a better way.

How do I turn off Thumb instructions?

Here’s what to do in Xcode:

Open your project
Choose Project -> Edit Project Settings
In the Project Info window, choose the Build tab
In the search box, type “thumb“
You should see a “Compile for Thumb” setting. Uncheck it. (Click image to enlarge.)
Clean and rebuild your project.

That’s it! If you don’t have the setting, make sure the Active SDK is set to Device. The setting isn’t applicable to the Simulator.

What kind of frame rate boost will I see?

I had improvements of around 20, 30, and 50%. Hopefully you will see even bigger ones!

Cheetah3D header file converter for iPhone

Rob Bajorek — Sun, 10 May 2009 04:11:23 +0000

[Update 2009/06/04: Version 2.0.1 released. Bug fix release, see here for more information.]

It’s ready! The promised Cheetah3D -> iPhone header converter is right here:

c3d_to_iphone_h.pl (zipped)

With this program you can convert exported Cheetah3D OpenGL .h files to an iPhone-compatible format.

Please read the comments at the top of the program file for usage information. I tested this on Mac OS X 10.5.6, but it should work on any system with Perl 5. I purposely did not use any external modules (no messing with CPAN here.)

The software is free, licensed under GPL 3. If you try it, please send feedback or respond in the comments. Thanks!

You Have to Learn the Magic

Rob Bajorek — Sat, 09 May 2009 04:09:52 +0000

Bad things can happen when you don’t understand what you’re doing.

When writing my first iPhone application in Objective-C, I banged my head against the wall of memory management. EXC_BAD_ACCESS became a frequent and unwelcome guest during testing.

I have a C/C++ background, so picking up Objective-C was not particularly difficult. However, Objective-C objects are a different beast than I was used to. I soon noticed a theme while debugging my app; crashes happened around the words release and dealloc a lot.

I started sprinkling retains throughout my code, hoping to ward off the memory errors. Sometimes it worked, sometimes I created a leak, and sometimes the crash jumped somewhere else. It was like playing whack-a-mole. Bash a bug in one place, and it popped up in another.

The problem was, to me, Objective-C memory management was something magical. I created and deleted objects all the time, and usually it worked. But, I didn’t know the rules for when to retain. I was trusting the object fairies to know what I wanted to keep and what to whisk away.

Eventually, I stopped and said “There is something fundamental that I’m missing.” I spent an hour reading Apple’s Memory Management Programming Guide for Cocoa. It was like flipping on a switch in my head. I went back to my code, ripped out the useless retains, then picked off the bugs one by one.

Magical thinking is a recipe for disaster. You need to understand the tools you use. If something is a black box to you, take a crowbar and rip it open.

Don’t trust the fairies. They don’t take the support calls from your frustrated customers. Learn the magic yourself.

Finding a 3D Modelling Application for iPhone Development

Rob Bajorek — Thu, 07 May 2009 05:10:30 +0000

After starting down the road of OpenGL development on the iPhone, I knew I needed a 3D modeling application to do anything fancier than spheres and cubes. My first try at an application was Blender. Blender has a lot of fans, but it’s also quite complicated. Just going through the tutorials was a chore. I didn’t want to learn how to draw fancy shapes like monkeys; simple polygons were sufficient.

After getting some basic models together in Blender, I had difficulty exporting into a usable format for the iPhone. The Wavefront OBJ format is the generic 3D model standard, and there is an importer for iPhone out there. It’s not feature complete, and doesn’t support UV texture mapping at this time. That’s a big hole for my purposes.

I played with Blender for a couple of days, but I struggled getting textured Blender objects into my iPhone project. Other people do it, so I’m sure it’s my lack of knowledge in that field. However, I don’t plan on being a 3d modeler; I’m the software architect. I need to spend my time on my area of expertise. But my needs were simple (mostly basic textured polygons), so I still preferred to do it myself.

What did I do? I ended up buying Cheetah3D, made my shapes quickly (and easily!), and exported it to a .h file in under 15 minutes. Now that’s what was looking for from Blender!

All done? Close, but not quite. Cheetah3D’s .h export feature makes an OpenGL-compatible file, not an OpenGL ES one. But, it took under an hour to hammer out a Perl program to convert the header file into an iPhone-usable one. Now I just run my Perl program over Cheetah’s exports and *poof*! Add the new header file to my iPhone project, import it at the appropriate place, and it Just Works.

End result? Cheetah3D is doing everything I need in a 3D tool. Not to say that Blender is a bad program. Far from it; it has an enormous amount of power and it’s free. But just like you won’t recommend Photoshop to get rid of red-eye, for my basic needs Cheetah3D does the job.

I have some requests for my Perl program, so as soon as I clean it up I’ll put it out for you to use.

[Update 2009/05/09] The Cheetah3D -> iPhone header converter has been posted.

My Start with OpenGL ES for iPhone

Rob Bajorek — Thu, 07 May 2009 04:57:01 +0000

This post is about my start at OpenGL programming on the iPhone.

I have an iPhone project that needs animation. After considering using 2D vs. 3D objects, OpenGL looked like the best option. Once I made that decision, I needed to start learning OpenGL. And how did that go? Let’s just say learning OpenGL is a non-trivial exercise.

First stop, the Apple Docs

The natural place to start learning OpenGl for iPhone is Apple. The iPhone Developer site has a lot of information about iPhone programming. In particular, the iPhone Application Programming Guide has a section on OpenGL ES. The information starts with setting up a drawing context and view for OpenGL. There are a number of suggestions, lists of supported features, and comparisons between the simulator and the device. But, it doesn’t really talk about programming in OpenGL. In short, it’s a great list of tips, but it assumes you already know what you’re doing. Surely I’ll come back to this page, but it’s not the place to start.

Apple did include some links, though. That’s where I went next.

OpenGL ES, the standard

I said before that iPhone OpenGL is not the full spec. It’s a special system designed for embedded devices and consoles called OpenGL ES, specifically version 1.1. The keepers of the standard are the Khronos Group.

The main document that I used from Khronos was the OpenGL ES 1.1.12 Full Specification (PDF). This document describes the specification, although the target audience is the OpenGL ES implementor, not the application programmer. Still, I picked up core concepts like matrix modes and building polygons. I couldn’t actually do anything with that knowledge since it didn’t tell me how to build an app.

At this point, I decided to ask Google.

The Red Book

I looked through some forums and tutorials, and the suggestion I tried next was to learn from the “official” guide to OpenGL, AKA the Red Book. By far, the official guide was the best introduction I found to OpenGL. This guide is an actual introduction, teaching you how to program from scratch.

This reminds me of an important point; OpenGL is a C API, not an Objective-C one. No classes or methods here. It’s globals and functions. There’s not much difference, but it may confuse you a bit if you started with Objective-C.

After digging into this book, I started to understand how OpenGL works and I could actually write code! It didn’t translate one-to-one to the iPhone because this is an OpenGL book, not an OpenGL ES one. However, it wasn’t difficult to apply the book to the iPhone. If I did get stuck, someone else did too and I found an answer from Google.

Also, Apple’s OpenGL ES examples made more sense. I started with those and built on them while going through the Red Book.

The Recommendation

I feel comfortable with OpenGL ES now. In fact, I already have a working 3D app integrated with the Bullet Physics library (a topic for another day.) My recommendation if you’re starting from scratch is to use the Red Book and the OpenGL examples from Apple. Play with the example projects until you feel comfortable, then go from there.

Welcome to Cocoa Swirl!

Rob Bajorek — Thu, 07 May 2009 04:20:56 +0000

Hello, and welcome!

This blog is the new home for my thoughts on developing software for Mac and iPhone. My old blog was at the website of my company, SakariTech. The system I used there wasn’t flexible enough, so I’ve moved it to this new domain and backend.

Please go to my contact page if you’d like to get ahold of me. Suggestions and comments are welcome.

Thanks for visiting!