I have this property synthesized and declared in my class 'ClassA'
#interface ClassA
#property (nonatomic, retain) NameFieldCell* nameCell;
#end
I know that the rule says that the nameCell property should be released in my dealloc method when it is declared with retain|copy|...
However, 'ClassA' gets instantiated lazily and sometimes the nameCell property is not even used, which means that I don't use its setter method nor access it nor retain it explicitly.
Should I still be calling [nameCell release] in my dealloc method? I find it difficult to understand that I should be releasing something that is not even initialized. And since it is not initialized, the reference counter is 0 and makes no sense to release it? Or is nameCell somehow retained automatically when instantiating 'ClassA' even if I am not making use of it?
In Objective-C, the memory allocated by alloc for a class is initialized to all-bits-zero on allocation (and then the isa ivar is set), which results in nameCell's backing ivar being set to nil by default. And since it is not an error to send a message to nil in Objective-C (the message is just ignored), you are free to just call [nameCell release] without worrying about whether nameCell was ever set.
If nameCell is nil, then [nameCell release] has no effect. This makes it easy to cover both cases, so yes, you should release it in your dealloc method.
That or start using ARC, and you won't have to worry about it.
Related
Subview has a reference to superview, while superview also has reference (subviews) to subview.
I'm wondering why this doesn't cause retain cycle?
UIView's superview property is declared as
#property(nonatomic, readonly) UIView *superview;
In Objective-C, properties declared without a different ownership specifier are assign by default strong by default as of the introduction of ARC, however, the UIKit headers appear to not be using ARC, so this property is most like assign. Note also, since the property is readonly, there is most likely a custom getter in the source, so the ownership specifier in the property doesn't necessarily tell us anything. It's safe to assume that Apple has implemented it in such a way as to avoid retain cycles.
assign is equivalent to __unsafe_unretained, which is a non-zeroing weak reference. This means that it does not retain the object, but will not be set to nil when the object is deallocated. This has higher performance than weak (since it doesn't need to be checked and zeroed), but unsafe, since you could be accessing garbage memory if the referenced object is deallocated.
Also note, the property is declared as readonly, which means it could actually be implemented as a method that returns a private instance variable, or does something else entirely that we don't know about. Basically, all that matters is that you can assume that this property does not retain the object it refers to.
In new code today, you should be using weak instead of assign.
I have a #class Foo which contains a __weak id bar ivar. Several actions from methods in different classes can cause the object to disappear and thus get bar niled.
I want to perform an action when the ivar is automatically niled by ARC.
If possible, I would want to avoid turning bar into a property or using Key-Value Observing.
Is this even possible? If not, can KVO be used against non-property ivars?
I was led here by a duplicate question, here is what I answered:
You can't do that with KVO, but you can still get a notification and emulate this by associating an object with your iVar using objc_setAssociatedObject(), it will be deallocated when the weak variable dies.
#interface WeakObjectDeathNotifier : NSObject
#end
#implementation WeakObjectDeathNotifier
- (void)dealloc
{
// the code that shall fire when the property will be set to nil
}
#end
You can build on top of that very elaborate notifiers, using NSNotificationCenter or just custom blocks, depending on how heavily you rely on that for a specific ivar case or for lots of them.
The good thing about this solution is that it works with any __weak ivar, even if you don't control the type the __weak ivar has.
KVO cannot be successfully used on non-property IVARs.
You cannot detect from the runtime when Objective-C's ARC nils an IVAR.
I suggest to override dealloc. If you know the type of the object that will be allocated, and it's a custom class (otherwise subclass it), you can perform the action when the object is deallocated, which is exactly what happens when ARC sets the retain count to zero and sets the weak variable to nil.
I had a library designed for ARC and iOS 5, but a customer wanted to build for iOS 4.x. I converted properties with the weak qualifer to unsafe_unretained, however now it seems I am running into memory corruption-esq crashes.
In the case of the crash, I have a delegate property like this
#property (unsafe_unretained) id<MYDelegateProtocol> delegate;
and I #synthesize the ivar.
whenever I want to call a method on the delegate, I check if it is nil, and if it is not, then I call the method, since I have no optional methods in that protocol, I don't check respondsToSelector.
However, since changing the weak to unsafe_unretained, I have found that apparently the reference goes away, and I am left with a dangling pointer. If I put a breakpoint on ObjC Exceptions, (for unrecognized message), and then po the address of the object, I see that it is an object that is not even implementing the protocol of the delegate, so of course it crashes.
When using unsafe_unretained how can I know that the reference has "gone away"? My code relied on the pointer being zeroed out before.
You have an object ownership problem. An object that has been released won't be nil, it would just be pointing at the address where the object used to be. An nil pointer would point to 0x0. You need to analyze how come your architecture has a delegate that is being released while the record being delegated is alive. On some special circumstances, objects being delegated might retain their delegates (like NSURLConnection). On other cases, objects being delegated are a property of their delegates, in which case, the delegation needs to be cleared out before deallocation. Analyze your pattern and/or provide more information.
Try this class I developed iOSWeakForwarder
When using unsafe_unretained how can I know that the reference has
"gone away"? My code relied on the pointer being zeroed out before.
This has to be determined at compile time by you. Often, the object that is the delegate should set the delegate property of the object delegating to it to nil in the dealloc method. For example:
- (void)dealloc
{
if (_httpRequest.delegate == self)
_httpRequest.delegate = nil;
}
Hope this helps!
Though I'm sure they exists, I'm having difficulties finding or pinning down an official best practice for declaring outlets in a ViewController.
There are 3 options so far as I can see:
ivar only
property only
property backed with an ivar
Xcode currently crashes when I try and auto-generate a property by dragging into my ViewController from IB, but from what I remember, doing so creates a property without an ivar. It is also possible to drag into the ivar section and this will create an ivar without a property. This suggests that property-only and ivar only outlets are both OK with apple.
So in viewDidUnload we need to assign nil to any of our outlets, but what about dealloc. If we have used a property without an ivar, how can we release our outlet give that we are not supposed to use any accessors in an init or dealloc?
It seems to me that the only pattern which would allow us to release our outlet without an accessor is using a property backed with an ivar, so we can manually release our ivar in dealloc without using its accessor, however this is the one option which Apple's code-generation doesn't support.
As a rule of thumb, I usually create accessors for IBOutlets.
In ARC or non-ARC projects I usually do the following:
//.h (ARC)
#property (nonatomic, weak) IBOutlet UILabel* myLabel;
//.h (non-ARC)
#property (nonatomic, retain) IBOutlet UILabel* myLabel;
//.m
#synthesize myLabel;
In this manner you can let the compiler to create an instance variable for you. But you can also declare your instance variable and tell the compiler to use that.
Then you can use that accessors/instance variable wherever you want.
The Apple Memory Management guide says that you have to avoid accessors methods in init or dealloc methods when you have non-ARC projects. So, for example:
// (non-ARC)
- (void)dealloc
{
[myLabel release]; myLabel = nil; // I'm using the instance variable here!
[super dealloc];
}
This is very important in non-ARC projects. The reason is that, if there is no accessor, KVC will assign the nib object to the instance variable and will put a retain on it. If you forget to release it, you could have a memory leak. Using an accessor force you to release that object at the end.
I strongly suggest to read friday-qa-2012-04-13-nib-memory-management by Mike Ash. It's a very cool article on nib and memory management.
Hope it helps.
Here's my understanding
Use properties for variables that will be accessed by other classes, either read from (getters) or written to (setters). Both setters and getters are synthesized for properties.
Use ivars for variables that will be used internally by the owning class only, that is, other classes will not set or get their values.
Sure you can use properties in lieu of ivars, but they incur the function-call overhead whenever they're accessed. So if you have an internal variable that is accessed by your class a LOT, the function calls will affect the real-time performance, and this can be avoided by declaring them as ivars.
It's now more than 5 months that I'm in Objective-C, I've also got my first app published in the App Store, but I still have a doubt about a core functionality of the language.
When am I supposed to use self accessing iVars and when I'm not?
When releasing an outlet you write self.outlet = nil in viewDidUnload, instead in dealloc you write [outlet release]. Why?
When you write self.outlet = nil the method [self setOutlet:nil]; is called. When you write outlet = nil; you access variable outlet directly.
if you use #synthesize outlet; then method setOutlet: is generated automatically and it releases object before assigning new one if you declared property as #property (retain) NSObject outlet;.
Very very important blog to understand about properties getter-setter method in objective c
Understanding your (Objective-C) self
http://useyourloaf.com/blog/2011/2/8/understanding-your-objective-c-self.html
You use self when you are refering to a #property.
Usually it will have been #synthesize'd.
You do not use self if you are refering to a "private" variable. Typically, I use properties for UI elements such as UIButtons or for elements I want easily reachable from other classes.
You can use the #private, #protected modifiers to explicitly enforce visibility. You cannot however use private methods, that do not exist in Objective-C.
The part about nil, release and dealloc is unrelated to the use of "self". You release what you retained, you nil what is autoretained.
You should read the Objective-C guide, it's well written and very enlightening.
You use self. when you're accessing properties of class that you're in (hence self). Basically you use self when you want to retain a value, but is only when you have retain in your property definition.
release just releases object that you've retained. You shouldn't release something that you haven't retained cuz it will lead to crash (zombie object).