Using UIScrollView


Hey All,
I have a question about the following three lines of code (bottom of p. 96):
UIScrollView *scrollView = [[UIScrollView alloc] initWithFrame:wholeWindow];
[window addSubview:scrollView];
[scrollView release];

My question is regarding the line 3. By releasing the scrollView instance we are decrementing the count by 1. I’m assuming in line 2, we are increasing the retain count thus scrollView is still going to be around. It doesn’t make much sense to me to create an object in line 1 and then destroy it right away in line 3 without using it. Does this mean that ‘window’ is actually in charge of releasing scrollView?



Yes, by adding a view as a subview, the superview retains it. “Takes ownership” is the term we use, instead of “take


[quote=“JoeConway”]Yes, by adding a view as a subview, the superview retains it. “Takes ownership” is the term we use, instead of “take

OK Joe, you are BUSTED!

On the thread "Releasing view after added to subview - Memory Mgmt"

You said “However, it is safer to do it the way in the book because you keep a pointer to this object as an instance variable, and there really should be a retain for each pointer (the window’s and the controller’s pointers).” In other words, it is bad practice to continue to use a pointer variable to an object which you handed over control to another object.

On another note, this clarifies a misapprehension I had regarding pointer variables after issuing a release. After the [scrollView release], I thought that now the “scrollView” pointer is no longer valid, or is up for grabs and would have accessed the UIScrollView object with [[window subviews] objectAtIndex:0]. Just read the documentation on release, and sure enough, all it does is decrement the retain count, it does NOT through the pointer variable (in this case “scrollView”) to the wolves.



Correct, sending a message will change nothing about the pointer. A pointer is really just a number, the address in memory where the object it points to lives. Sending a message just resolves to a C function call (not always objc_msgSend, but usually).

- (void)method
    [object release]; // resolves to objc_msgSend(object, @selector(release));

Since this function call passes “object”, which is just a number, by value, “object” in the scope of this method will not be changed regardless of what happens in that method.


Alright, so you are not busted. I thought I had a contradiction where you release the scrollView but not the view object.

Both objects get assigned as subviews and get retained, so why not also release view? The difference is that view is an ivar and we want to hold on to an extra retain count as long as the object exists in which the ivar lives, in this case the HypnoTimeAppDelegate. So we balance out the alloc for the view with a release in the dealloc method.

However, scrollView is just a temporary pointer variable used to instantiate and then add to the array of subviews. Since the array of subviews can manage its own objects, we can immediately do a release.

Though I still have a nit. Should the naming convention for objects like scrollView be aScrollView to emphasize this point to anyone trying to read your code?


Other than using camel-case, there isn’t a widely adopted convention for naming variables. If it makes sense for you to prefix an “a” before local variables and leave the “a” out of ivars, then it seems like a perfectly rational thing to do. :slight_smile: