Releasing view controllers


#1

I’ve finally learn’t how a XIB (NIB) is loaded “automatically”… great. Very clever.
But my question is (p. 178) -
Shouldn’t the view controller be released after it’s been pushed onto the stack?
and then it should be set to nil (or I get a reliable crash on selecting another row).
However, you do neither (which works as well) - wouldn’t this cause a leak?
Thanks
Peter


#2

You are right: that view controller is not being released. But that was intentional.

We decided that we would just create that view controller once, keep it around, and reuse it. If the user goes to that screen repeatedly, this approach should make it a little faster.

If we were more worried about memory, we would have released it and created a new one each time the user went to the detail view.


#3

Equally interesting is a line on the next page:

Two things: Downloaded code does not use @property/@synthesize combo, and you guys could have said at least something about this assign keyword. Why are you not using expected retain? Does that have anything to do with retain cycles described on page 99? But here we don’t have a clear child / parent relationship and I think that one of the general memory rules in Objective C was: any object that needs another object for a while should retain it.


#4

The assign keyword for properties is discussed (albeit, briefly) in the Objective-C and Memory Management chapters. Basically, a synthesized property with the assign keyword looks like this:

- (void)setFoo:(id)f
{
     foo = f;
}

The reason it is not retained by ItemDetailViewController is more of a design choice than anything else. All of the possession instances belong to the array that belongs to ItemsViewController. The ItemDetailViewController is also owned by the ItemsViewController. When a possession is tapped, the ItemsViewController gives the ItemDetailViewController a pointer to that Possession instance so that the ItemDetailViewController can read its ivars and change its ivars.

Given the way this application works, we know that when ItemDetailViewController is on the screen the Possession object is valid and cannot be released. (It is valid because we just set it and pushed the detail VC onto the stack and it cannot be released because you can only remove Possessions from the array while ItemsViewController is on the screen.) In a sense, the ItemsViewController is saying, “Detail View Controller, I have this Possession I want you to play with. Don’t worry about where I got it from or who owns it, because I promise that as long as you are on the screen, that Possession will remain valid.” We call the ItemDetailViewController’s relationship with the editingPossession a “weak reference”.

You could just as easily use retain here, as long as you coupled it with a release in ItemDetailViewController’s viewDidDisappear: method. But because there are certain truths about the relationship between ItemsViewController, its possessions and ItemDetailViewController (ItemsViewController guarantees the existence of a Possession it passes to ItemDetailViewController), we can safely hand the pointer off to the ItemDetailViewController and not have ItemDetailViewController take ownership. Also, the only way an ItemDetailViewController can appear on the screen is by ItemsViewController’s prompting (coupled with a setEditingPossession: right before it), this is okay.


#5

Thanks for the quick reply,

[quote]The assign keyword for properties is discussed (albeit, briefly) in the Objective-C and Memory Management chapters. Basically, a synthesized property with the assign keyword looks like this:

- (void)setFoo:(id)f { foo = f; }[/quote]

Well, ItemDetailViewController.m that comes with the download for the book has it that way:

- (void)setEditingPossession:(Possession *)possession { // Keep a pointer to the incoming possession editingPossession = possession; }

And I think I understand your motives for this type of design. But as I typed the code this morning it felt more suited to straight C programming than Objective C / Cocoa way of doing things.

My day job is in plain C and when I work on the iPhone I’m forcing myself into a different mindset. So, maybe I am overdoing it.


#6

A decent Objective-C programmer can get away with being iffy on C. An excellent Objective-C programmer knows (and loves) C very well.

Many times, especially with data objects that are sent lots of messages a few hundred times in an event (like points, vectors, matrices, etc.), using an Objective-C class has a detrimental effect on speed. In those cases, you have to “drop down” to C structures. I put quotes around “drop down” because, while that is good way to explain it, it shouldn’t really be thought of that way - Objective-C is C with some additions. (Versus that other C superset, C++, which completely mangles C.)

Using the assign property for Objective-C objects is something you will occasionally see and use. Weak references have some uses that go beyond preventing retain cycles.

Also, the solutions fall out of sync with the exact text of the book as we update. I’ll try and update those soon.