Can anyone tell me the difference between [self.property release] and [property release] . I am asking this because in one of the view controller in my application, I am doing [self.property release] and pushing this view controller in to the navigation stack, when I pop this view controller its showing the error EXC_BAD_INSTRUCTION but when i do [property release] everything is working fine...? Can any one tell me where I am going wrong. I am new to iPhone app development.
The distinction is self.myProperty is an accessor method for the instance variable myProperty. Accessor methods are generated by #synthesize, or can be defined explicitly as
-(Type*) myProperty;
-(void) setMyProperty:(Type*)p;
So, assuming you've defined the accessor as (the key is retain)
#property (retain) Type* myProperty;
then
[myProperty release];
myProperty = nil;
is equivalent to
self.myProperty = nil;
In general, it's good practice to set released objects to nil so that you don't accidentally try to use (or over release) them.
There is no good reason to call [self.property release].
[property release] sends the release message to the property instance variable and is almost certainly what you want to do.
[self.property release] sends the release message to the object returned by self.property. The result of this will depend on whether the property is defined as assign / copy / retain and so basically you are probably releasing a different object to the one that you think you are.
Related
I've been trough some tutorials and some information, but I dont have a straight answer about the best way or the best place to release variables.
Lets see this situation, I have these 2 variables:
#property (nonatomic, strong) IBOutlet UIButton *myButton;
#property (nonatomic, strong) NSString *myString;
...
#synthesize myButton = _myButton, myString = _myString;
Is this the best way of releasing them?:
-(void)viewDidUnload {
self.myButton = nil;
self.myString = nil;
[super viewDidUnload];
}
-(void)dealloc{
[_myButton release];
[_myString release];
[super dealloc];
}
I understand more than enough when dealloc is called, and when viewDidUnload is called, I just want to know if that way is correct, and why it has to be done in that way.
Thanks guys
It is recommended to not use property accessor methods in init and dealloc, since they might expect some other information in the object to exist. If you know what you are doing, there is really no problem of using self.myButton = nil also in dealloc. However, there is really no use of setting them to nil since the object is being destroyed - unless some code is accidently run from dealloc (as the accessor methods I mentioned above).
In viewDidUnload, you want to set your members to nil instead of only releasing them, since your object will continue to exist and does not want to access dangling pointers.
So, your example should be the best performance and safest way of programming.
There are other ways, such as not declaring the IBOutlets as properties, or declaring them as properties without retaining. I find that in most cases I prefer to have them be retained properties, which I then have to explicitly release. An example of this is when you switch from one view controller to another. As one view controller is dismissed, its views are removed and they are released. Any IBOutlet UILabels on that view would get released too if I don't have them retained. That means that when I flip back to the old view, I have to go through and reset my labels and controls to their last values, when I could have easily kept them saved if I just retain the IBOutlet.
I have read the documentation about the use of the viewDidUnload method. I thought I did understand the meaning of this method
1) I use retain with #propery in the .h file and #syntesize in the .m-file. I assign object with a value using self.object = something. In this case I would set self.object = nil; in the viewDidUnload method.
2) I do not retain the object in the .h-file but I am allocing and init the object in the viewDidLoad method. In the dealloc method I have the [object release]; In the viewDidUnload method I also set [object release]; because the next time the view will appear, the object will be created in the viewDidLoad method
Hope, this will help you...
I have a property that has (nonatomic, assign) as attributes.
In a method, I then am retaining that variable then releasing it a line after.
Static analyzer is giving warning that incorrect decrement of the reference count of object....
Can I not do this
#property (nonatomic, assign) Class *iVar;
[self.iVar retain];
[self.iVar removeFromSuperview];
[self insertSubview:self.iVar atIndex:self.iVar.index];
[self.iVar release];
Since the retain and release both happen in the same method, you might want to copy the property to a local variable and then work with that:
UIView *someView = self.interestingView;
[someView retain];
//...do some stuff...
[someView release];
That at least provides some protection in case the "some stuff" part happens to modify self.interestingView. And it'll probably satisfy the static analyzer, too.
In general, I would avoid retaining/releasing variables that back properties outside the accessors for those properties, except for a few well defined situations such as -dealloc. Similarly, avoid directly retaining/releasing the result of a property access, as in [self.foo retain]. If that property is changed before you get to the release, you end up with both a leak and, later, an over-release.
The trouble is that you're not working with a variable; you're working with the result of a property accessor. Each time you access the property, the static analyzer applies the normal memory management rules for an object returned from a method — namely, you shouldn't be releasing it. If you change it to use an actual local or instance variable, the warning will go away.
I just tested a similar example,
You will appease the static analyzer by not using property notation
[iVar retain];
[self.iVar removeFromSuperview];
[self insertSubview:self.iVar atIndex:self.iVar.index];
[iVar release];
Or you could use a temporary variable.
I have a MBProgressHUD that I allocate as follows:
self.progressHUD_ = [[[MBProgressHUD alloc] initWithView:self.view] autorelease];
if I call removeFromSuperview then would I have to call progressHUD release again? Also if I declare a property with something like this:
NSString * title_;
#property (nonatomic, retain) NSString * title_;
then it is guaranteed that in my dealloc I should have a release on title right?
If progressHUD_ is a retain property, then you will have to release it in dealloc. However, the nice thing about a retain property is that you only have to set it to nil to reclaim the memory; making sure to use "self." before.
e.g.
self.<property_name> = nil;
// or in your case
self.progressHUD_ = nil;
// the following will not release it because it's not accessing the property:
progressHUD_ = nil
I do not recommend using [progressHUD_ release] because it can cause problems. e.g. if elsewhere you had released progressHUD_ and not set it to nil, you may accidentally release a pointer which is no longer allocated (dangling pointer).
I also recommend calling self.progressHUD_ = nil; in viewDidUnload which is called during low memory conditions and the view is not showing. It doesn't kill your class instance, but just unloads the view. And of course this assumes that you call self.progressHUD_ = [[[MBProgressHUD alloc] initWithView:self.view] autorelease]; in viewDidLoad rather than in init...
No, you don't have to release it again. Views retain their subviews and release them again automatically when you call removeFromSuperview. As long as the view has been autoreleased when you attach it to the view, it will be released when it is removed from the view.
I didn't quite understand your second question, but yes, you have to release any properties of type "retain" or "copy" in your dealloc statement. You have to write those release statements manually, they aren't added automatically (unless you are using ARC of course, which I strongly recommend).
How is your progressHUD_ property defined? (btw, the ivar should have a trailing underscore, but not the property name).
In case it is defined as (retain, whatever), you will have to release it again:
When you create it, its retainCount is +1.
When you assign it to your property, its retainCount will be increased by one.
When you add it as a subview to the parent view, its retainCount will be increased by one.
At some point, autorelease will eventually decrease it by 1, but the view and the property still hold on to it.
So you'll have to either set your property to nil or call release on the ivar in your dealloc method.
Also, you probably want to use copy instead of retain when defining an NSString property. And yes: you'll have to release it either way.
I am subclassing NSURLConnection, and used MGTwitterEngine as a base to help me get started. That may be irrelevant. However, I noticed in their code they don't use #property or #synthesize for their ivars. They have wrapped the ivars in accessor methods which look like this:
- (NSString *)identifier {
return [[_identifier retain] autorelease];
}
My question is two part. First, what effect does retain followed by autorelease have? It seems to me it would cancel itself, or worse yet leak.
Second, if I were to change the header file to have:
#property (nonatomic, retain, readonly) NSString* _identifier;
And used #synthesize indentifier = _identifier, wouldn't this do the same thing as the accessor method without having to write it?
Maybe it is just two different ways to do the same thing. But I wanted to ensure I have the correct understanding. Thanks.
Using #synthesize will actually only create a setter and a getter method. The code that is auto generated for you is guaranteed to use proper memory management, so that you do not need to worry.
MGTwitterEngines use of return [[ivar retain] autorelease] is actually the correct way to do it. Lets have two examples.
Assume a getter is defined as this:
-(Foo)foo {
return foo;
}
And then we execute this code:
bar = [[bar alloc] init]; // bar has aretain count of 1.
foo = bar.foo; // foo har a retain count of 1 (owned by bar).
[bar release]; // Bar and all it's ivars are released imidiatetly!
[foo doSomething]; // This will crash since the previous line released foo.
If we instead change the getter to this:
-(Foo)foo {
return [[foo retain] autorelease];
}
bar = [[bar alloc] init]; // bar has a retain count of 1
foo = bar.foo; // foo has a retain count of 2 (one owned by bar, 1 owned by autorelease pool).
[bar release]; // Bar and all it's ivars are released imidiatetly!
[foo doSomething]; // Will not crash since foo is still alive and owned by autorelease pool.
Hope this explains why you should always return properly autoreleased objects from all your getters. It is important that any return value can survive the deallocation of it's parent, since no class ca guarantee what a client will do with it's values once it is exposed to the wild.
Retain followed by autorelease does exactly what you might think it does. It sends the object a retain message and then sends it an autorelease message. Remember that autoreleasing an object adds that object to the autorelease pool but does not release it yet. The autorelease pool will send the object a release message at the end of the current iteration of the run loop. So, a retain followed by autorelease essentially says, "Make sure this object stays around until the end of the the current iteration of the run loop." If you need the returned value to hang around longer, you can retain it. If not, do nothing and the autorelease pool will handle it.
In this case, the string being sent retain and autorelease messages is a property. It's already retained by the parent object. So you might wonder why do this retain and autorelease thing at all? Well, there's no guarantee that the object won't release _identifier before the current iteration of the run loop ends. Consider this example:
- (NSString *)identifier { return _identifier; }
- (void)aMethod {
NSString *localId = [self identifier]; // localId refers to _identifier which is only retained by self
[self methodThatChangesIdentifierAndReleasesItsOldValue]; // self releases _identifier
NSLog(#"%#", localId); // crash, because localId (old value of _identifier) has been released
}
In this case, the returned identifier isn't retained and autoreleased. The NSLog line crashes because localId refers to a released string. However, had we used retain and autorelease in the getter, there would be no crash because localId would not be released until the end of the current iteration of the run loop.
As far as I know, your replacement with an identifier property would be just as good. It might not be identical code, but the effect should be the same.
Apple explains this well in Implementing Accessor Methods. The method quoted by you (named "Technique 1" by Apple) helps avoid bugs if the caller assigns a new value to the identifier property and then expects the retrieved value to still be available. It won't be needed most of the time but just returning the ivar value can lead to bugs that are hard to track down.
Generally one retains then autoreleases if you are returning something that you didn't own the first place. It will only leak if you own _identifier and there is a mismatch of retain/alloc/etc versus release/autorelease sent to that object.
Secondly, yeah you generally don't have to write the headers if you aren't doing something special beyond what the general boilerplate looks like. Apple has good documentation on properties, I suggest if you're still fuzzy, you look at those.
Regarding over-releasing. Say I have a instance variable defined in Test.h
NSString *mystring;
In my implementation Test.m I do not initialize the variable mystring anywhere. But I release it in dealloc:
-(void)dealloc {
[mystring release];
}
Is this now over-released? I've been doing the following in dealloc to avoid any issues, however, is this really necessary?
-(void)dealloc {
if (mystring) [mystring release];
}
It seems that [nil release] shouldn't do anything, can someone verify this with class members?
There is no way to over-release something that never existed in the first place.
Instance variables are initialized to nil and, thus, [mystring release] is messaging nil which is just fine in Objective-C.
Your -dealloc methods do need to call [super dealloc] at the end, though.
First, why are you creating a variable at the class level that you're not initializing anywhere?
As this post is tagged iphone and it's IMPORTANT to manage your memory in the iphone environment it's always a good idea to release something if you've defined even if you don't assign it.
You can call release on an uninitialized variable without any problems, and be sure to [super dealloc]