This may sound a newbie question, however I'm new to iOS dev.
Suppose with have this code.
UILabel* label = [[UILabel alloc] init];
...
[someScrollView addSubview:label];
...
label.text = #"Some Text";
is it good practice to modify the view after addSubview ?
Actually my concern is following probably, it is possible that label get released before reaching to label.text assignment, for instance in viewDidUnload, right ? and the assignment will fail.
Overall my questions are
it is good practice to modify views after addSubview ?
is it good practice to release view after addSubview, and later if I need to get any subview to look for it using following technique for (UIView *view in self.subviews) { if (...) ... } ?
It is fine to change properties of a view after you add it as a subview. Those properties will be applied (or animated) on the next turn of the runloop when UIKit renders stuff.
You should absolutely release your view after adding it as a subview IF you no longer need to own it. In other words, follow the memory management guidelines for all cocoa programming. Doing addSubview will cause the owing view to retain it (since it needs it). If you need to change a property on the view in the future though, you should retain it so you have access to it
Your code is fine as long as it is all in the same method and label is not reassigned during any of the ... sections.
Modifying a view before or after adding it to a subview makes no difference.
If you have allocated a view, then added it to a subview, and you don't wish to keep a separate reference to it, you should release it - this is standard memory management. The super view will retain its subviews.
To get hold of a reference to your subview again, your two options are:
Set the tag on the subview before adding it, then use viewWithTag: to get it later
Keep a reference to the subview as an instance variable (in this case, you wouldn't be releasing it after creating it, you'd release it on dealloc).
I’ve used both ways - modifying before and after and have not had any issues either way. The superview is retaining the subview, so if you don’t release the superview or set the subview to NIL somewhere, you’re pretty safe.
Yes, you need to release the view you added after addSubview, but easiest to do it like this:
UILabel* label = [[[UILabel alloc] init] autorelease];
Then it will be released automatically and you don’t have to worry about explicitly releasing it.
Related
I'm getting an strange case of excessive retain counts for a view controller that I'm loading when a button is pushed.
This is the code:
-(IBAction)new
{
if (!viewSpace)
viewSpace = [[ViewSpace alloc] initWithNibName:#"ViewSpace" bundle:nil];
viewSpace.delegate = self;
viewSpace.view.frame = CGRectMake(0, 0, viewSpace.view.frame.size.width, viewSpace.view.frame.size.height);
[self presentModalViewController:viewSpace animated:YES];
NSLog(#"Count Retain: %d",[viewSpace retainCount]);
}
-(void)viewSpaceWasDissmissed:(id)sender
{
[self dismissModalViewControllerAnimated:YES];
[viewSpace release];
NSLog(#"Count Retain: %d",[viewSpace retainCount]);
}
When the IBAction New is executed first time, the retain count is 5 when just is created. (It must be 1).
When the ViewSpace object must be unload calls viewSpaceWasDismissed function in order to remove the modal view and release the previous object.
The problem is that never the retain count reach 0 and the dealloc method of ViewSpace never is called causing memory leaks.
My question is how is possible that a recently created ViewController have 5 retains? I made sure that is never created before.
Thanks.
Cocoa is probably retaining the view controller 4 times internally for reasons of its own. This isn't a problem.
More generally, the -retainCount method is useless for reasons like this, and you should never call it. It will not help you, and it will confuse you.
To debug your leak, I suggest using the leaks Instrument, inspecting the object, and analyzing where each retain and release is coming from to determine whether any are incorrect.
Check the documentation for -retainCount. I believe it says that you should not be calling it yourself - you just need to take care of any retains that you cause, and don't worry about the 'actual' retain count.
You're doing two things wrong here:
The Current view controller retains the modally presented view controller and releaseds it when it is dismissed. So you should release viewSpace after it is presented, and you don't need the release message in the dismissModalViewController method. As an aside ViewSpace is a poor name for a view controller. I had to read to the line where you are presenting it as a view controller before I knew it was a view controller. I think ViewSpaceController is a more descriptive name.
You are using retainCount which is always a bad idea. All that matters is that in your new method you created an owned object (with the alloc) and you balanced that ownership with a release (or at least you will do when you put in the correction I suggested in point 1) That's it. You took ownership of an object and you released it. The retainCount method tells you absolutely nothing that can be of any use to you. Don't do it. Just balance ownerships with release, and that is all that matters.
I'm not 100% sure of every count but here are some:
Instantiation - 1
NIB - 1+
Strong Properties (1+)
Additionally any properties that list it as a strong property (in ARC).
I noticed that when you launch a nib and you use components of the controller in the nib design, it will increase reference counts (in a strong manner) on the controller instance.
does this retain my subview twice?
- (void)viewDidLoad
{
CGRect frame=CGRectMake(0, 0, 320, 460);
mapButtons*newButtons=[[mapButtons alloc] initWithFrame:frame];
self.mapButtons=newButtons;
[newButtons release];
[self.view addSubview:self.mapButtons];
[self.mapButtons addButtons:#"yo"];
once it is added to the view hierarchy with addSubview, does it get an additional retain count beyond that retained by the ivar, self.mapButtons?
i want to be able to manipulate this subview easily, hence the ivar; is this a good way, or is there a better way?
EDIT
You mention memory-wise so I think it may need some clearing up. Each object has a retain count which is incremented with retain and decremented with release. When the retain count reaches 0 a dealloc message is sent. So when you put an additional retain on an object you are not using anymore memory you are simply incrementing the counter and not doing any kind of duplication.
There are a couple of ways you can grab a reference to a view but the way you are doing it is a good way. An alternative would be to tag the view and retrieve it from self.view using
UIView *view = [self.view viewWithTag:tagId];
I prefer the ivar way e.g. how you have done it (this will change when ARC comes in) but I tend not to worry about the the actual retain count of an object. I concentrate on balancing my retain/releases.
Therefore I use the rule that if it's a local variable I try as far as possible to match my retain/release's within the scope it is defined in. The exception being ivar which are released in dealloc
Is it a leak if I have a view controller and allocate the view like this:
self.view = [[UIView alloc] initWithFrame:frame];
Do I need to do something like this:
UIView *v = [[UIView alloc] initWithFrame:frame];
self.view = v;
[v release];
Yes, the second one. Properties (self.view) retain their value usually.
Yes, it's a leak. Your solution is correct, or you can do:
view = [[UIView alloc] initWithFrame:frame];
Where view is an instance variable. But it's not such good practice. As commented below, in a UIViewController view is a superclass property, so my code example is doubly wrong. However, the principle that self.variable is invoking setVariable:, and will observe the retain style of the property declaration is worth noting. In such cases you can directly assign to the instance variable above, which omits the retain - and makes such code a horror to maintain, which explains why Apple's Objective C 2.0 property syntactic sugar isn't universally admired.
Corrected because Georg was entirely correct.
This depends on the declaration of the view property. If it's not a (retain) property, then you're fine. If it is a retaining property, you must call release.
You need to read the Cocoa Memory Management Rules.
You obtained the object with +alloc. Therefore, according to the rules, you are responsible for releasing it. Your own solution is perfectly fine, or you could do:
self.view = [[[UIView alloc] initWithFrame:frame] autorelease];
There is a very simple rule for Objective-C memory management. If you've sent retain message, you've to send release also. I do not know exceptions with this rule is SDK itself.
Here we've alloc, that sends retain itself (always), so you have to release object somewhere. You can do it in dealloc or right here, after assigning it to self.view.
In objective c, we need to maintain retain count of an object as zero after its purpose. So here in your code you must release the object. Then it will not create any leakage problems.
The second one you specified is the right way. It is not a compulsory , it is the way to express how effective our code is.
I have a very simple code to show a modal controller (nextController is a class member):
nextController = [[InstructionsScreen alloc] initWithNibName:#"InstructionsScreen" bundle:nil];
[self presentModalViewController:nextController animated:YES];
[nextController release];
And then when the controller should hide:
[self dismissModalViewControllerAnimated:YES];
nextController = nil;
All works good as expected, but when I run instrument Object Allocations it shows that after dismissing the modal controller the memory it allocated is not freed. This becomes a problem because when I show several controllers the memory is over ...
Can anybody give me some clues ? Clang doesn't see any problems, so I'm stuck hitting the memory limit, because the memory of the dismissed controllers won't get released.
EDIT: What I discovered up to now is that it seems to be a leak somewhere in Apple's stuff. Way to reproduce: XCode -> create new project with the template "Utility application". Don't write any code yourself. Just create a new utility application and run it with "Object allocations", choose to see "Created & Still living". Now flip the modal controller few times - you'll see the allocated memory only grows and grows every time the modal controller is appearing and when it's disappearing too ...
There is no leak in the code you show as far as I can see. There could be a leak in InstructionsScreen that would prevent it being deallocated.
I think it's worth running the Static Analyser to see if it finds a leak.
The leak in the Apple template code is interesting. It could be that there is a leak. It seems unlikely but obviously it's not impossible. I would say that it's more likely that it's a false-positive in Instruments, which is why I'd suggest using the Static Analyser.
(You might want to raise a bug report about the leak.)
Modal views are not subviews of the calling view but are instead subview of the apps window and are retained by the window itself. You generally you do not retain a reference to them in the controller that calls them. Instead, evoke the modal view and then have it communicate with the controller by defining the controller as the modal view's delegate.
I think that if you use synthesize to create the accessor for a nextController property defined with retain, then the accessor will retain any object assigned to the property. Simply setting the value to nil will not release the object unless the accessor is set up to do that and I don't think the autogenerated ones do.
You will expressly have to call release before setting to nil.
If this doesn't work, post the code for your definition of the nextController property.
I'm trying to implement my own version of NSViewController (for backwards compatibility), and I've hit a problem with bindings: Since bindings retain their target, I have a retain circle whenever I bind through File's owner.
So I thought I'd just explicitly remove my view from its superview and release the top level objects, and that would take care of the bindings, because my controller isn't holding on to the views anymore, so they release me and I can go away. But for some reason, my view controller still doesn't get released. Here's a sample app exhibiting the problem:
http://dl.dropbox.com/u/34351/BindingsLeak.zip
Build it, launch it, and hit Cmd-K ("Create Nib" in "Edit" menu) to load a NIB into the empty window. Hit Cmd-K again to release the first view controller (TestNibOwner) and load a new one. The old view controller never gets dealloced, though.
Remove the "value" binding on the checkbox, and it gets released just fine.
If you set breakpoints at the release/retain/autorelease overrides, you see that _NSBindingInfo retains the TestNibOwner, but never releases it in the leaking case.
Anyone know how to fix this?
Doing a little investigation with class-dump and friends, it looks like Apple has a private class called NSAutounbinder that takes care of this dirty work for classes such as NSViewController and NSWindowController. Can't really tell how it works or how to replicate it though.
So, I can't really answer your question on how to prevent the retain cycle from happening for arbitrary bindings in a loaded nib, but perhaps it's some consolation to know that Apple is cheating, and you're not missing anything obvious. :-)
One thing I've done for the same problem is to create a proxy NSObjectController inside my nib. My NSViewController-like class has a pointer to this proxy and all bindings are bound through it. When I want to cleanup the view controller, I then do [selfProxy setContent:nil] on the object controller and release the view controller. In this instance the NSObjectController proxy acts as the auto-unbinder in this case.
It's more manual and you can't just release the view by itself, but it does solve the retain problem.
I'd suggest you do this:
-(void) releaseTopLevelObjects
{
// Unbind the object controller's content by setting it to nil.
[selfProxy setContent:nil];
NSLog( #"topLevelObjects = %#", topLevelObjects );
[topLevelObjects release];
topLevelObjects = nil;
}
In your nib, bindings would happen through a path like:
selfProxy.content.representedObject.fooValue
When you remove your view from its superview, are you also sending it another -release message? It was created by unarchiving from the nib, right?