I have a very basic data class that is subclassed from NSObject. I declare a few strings, make sure they have properties (nonatomic, copy), and synthesize them. The only method I implemented was dealloc() which releases my strings. Can any memory problems arise from just this? Are there any other methods I need to implement?
Subclassing NSObject is something that we do all the time. Just follow the memory management rules, and you're good to go.
You could implement a custom init if you want to set anything up.
-(id)init {
if (!(self = [super init]))
return nil;
// Set things up you might need setting up.
return self;
}
But that's only if there's something you want to have ready before you call anything else on the class.
Just having a dealloc method should be fine, otherwise.
There won't be any problems. Subclassing NSObject is perfectly accepted, and in 99% of cases required.
By subclassing NSObject, your subclass receives all the required behaviour that is expected of any object in Cocoa/Cocoa Touch. This includes things like the reference counting memory management system using retain and release etc.
What you're doing is fine. Be sure to call [super dealloc] at the end of your subclass' -dealloc method.
Related
So, I have class:
#interface Controller : NSObject
{
UILabel* fileDescription;
}
#property(strong, nonatomic) UILabel* fileDescription;
Do I need use method dealloc where property fileDescription will equal nil?
For example:
-(void)dealloc
{
fileDescription = nil;
}
If not, who will dismiss memory used by fileDescription?
Generally you don't need to provide a subclassed dealloc method as ARC manages the lifetime of the instance variables.
However it can be useful to perform clean-up other than releasing objects, for example to remove an observer or close a network connection down cleanly. You are therefore allowed to subclass dealloc under ARC, but you are not allowed to call [super dealloc] from within the subclassed method.
In your particular case it's not required, however.
No.
You don't need dealloc method in ARC.
But if you want to do some cleanup tasks when your view is dismissing or released. It's the best place, In such case you can implement it.
For example:
You are running a timer in your view and it's updating your view. When you are dismissed the view you need to stop that timer. In that condition you can use dealloc method and stop timer there.
Similar for NSNotification observer.
If you are using ARC.
No need to use dealloc and release, compiler knows that your property and objects are strong / weak so it will manage it.
EDIT:
dealloc method is required if you use coreframework objects like CG... & CF.... Even you create observers for notifications you need to remove it and dealloc is the best place to removeObserver.
Ans is NO Because with ARC no need to dealloc.
As you are using ARC you don't have to use dealloc
Complier will set the autoreleasePool depending upon the scope of the property,variable or control. And it'll will release the memory. There are different types of autoreleasepool generally we can define them as function level,class level etc etc. Hope this helps.
Weird discovery, when I used a drag and drop to make a new IBOutlet, as shown below, not with a #property at all:
#interface SkinChoosingView : UIViewController {
IBOutlet UIActivityIndicatorView * activityIndicator;
}
Xcode inserted a -release and set the outlet to nil in viewDidUnload. I looked in viewDidLoad though, and no -retain was there! This went against everything I know about memory management.
I figure apple must know a thing or two about this stuff though, so is there something behind the scenes happening here? I have never had leaks from these types of IBOutlets, and I've never released them.
Yes, it automatically retains the outlet for you when loading the NIB file unless you explicitly declare the property associated with the outlet as an assigned property.
And since it retains the outlet for you, you must release in viewDidUnload as the outlets will be reloaded by the time next viewDidLoad is called.
The answer is that it uses "Key-Value Coading", which means it calls -setValue:forKey:, which has a "Default Search Pattern". For ivars, it does something like [ivar autorelease]; ivar = [newvalue retain];.
The "current best practice" is to stick IBOutlet on properties instead of ivars (see here). This makes it obvious what memory management pattern is being used and is more resilient to typos (e.g. if you misspell the ivar).
I am creating a subclass of a custom UITableViewCell. The superclass has some properties that it is releasing in the dealloc method. I have added one additional property in my subclass, so I made sure to override the dealloc method and release my new property.
My question is, since I overrode the dealloc method, will the properties that were released in super class dealloc method not get released (I AM calling [super dealloc])? Do I need to specifically release those in MY dealloc method?
If you are calling [super dealloc], then the superclass implementation of -dealloc will still be run. The superclass should be responsible for releasing its own properties. So no, you don't need to release the superclass properties. In fact, doing so will likely cause your application to crash.
If you are calling [super dealloc], you are fine. That method won't know if it was called by a subclass or directly by the runtime, and it will do its usual work and take care of its own properties as always.
Important: Call [super dealloc] last in your -dealloc method, after you've your own ivars and done anything else you need to do in -dealloc. There won't be anything left of your object when that method returns.
I am using #property(nonatomic, retain) for my IBOutlets for an iPhone application. However, I'm not sure how to make sure I'm managing memory with them properly. The IBOutlets are all set up in Interface Builder, so I'm never calling alloc manually. This means that I'm not sure when and if to deallocate them or when to set them to point to nil.
What are the best practices ensuring that no memory is leaked once the view unloads?
If you use #properties for yourIBOutlets and make the connections in IB then your controller is essentially retaining the IB objedcts with the property and is it therefore responsible for releasing them when it's done with them.
When are you done with them?
In every case you should be setting your properties self.propertyname = nil in your viewDidUnload method and again in dealloc of each viewController.
It's quite straight forward, IB manages everything else.
By default, the semantics of #property is retain, meaning that when the view controller loads the nib and connects IBOutlets, they get retaind by the #synthesized setter. Follow the standard rules of Cocoa memory managment: you must release these properties eventually or you will leak memory. dealloc is probably a good place to do this. On the iphone you can do this via self.outletProperty = nil. On OS X (when you're not using GC), the rules are the same, except you can use [self->outletProperty release] explicitly, bypassing the #synthesized setter.
You should do it like this....
[yourOutletVar release];
yourOutletVar = nil;
Please don't forget to set the IBOutlets to nil finally, because it is necessary to get rid of dangling pointers issue.
If I have something like a UILabel linked to a xib file, do I need to release it on dealloc of my view? The reason I ask is because I don't alloc it, which makes me think I don't need to release it either?
eg (in the header):
IBOutlet UILabel *lblExample;
in the implementation:
....
[lblExample setText:#"whatever"];
....
-(void)dealloc{
[lblExample release];//?????????
}
If you follow what is now considered to be best practice, you should release outlet properties, because you should have retained them in the set accessor:
#interface MyController : MySuperclass {
Control *uiElement;
}
#property (nonatomic, retain) IBOutlet Control *uiElement;
#end
#implementation MyController
#synthesize uiElement;
- (void)dealloc {
[uiElement release];
[super dealloc];
}
#end
The advantage of this approach is that it makes the memory management semantics explicit and clear, and it works consistently across all platforms for all nib files.
Note: The following comments apply only to iOS prior to 3.0. With 3.0 and later, you should instead simply nil out property values in viewDidUnload.
One consideration here, though, is when your controller might dispose of its user interface and reload it dynamically on demand (for example, if you have a view controller that loads a view from a nib file, but on request -- say under memory pressure -- releases it, with the expectation that it can be reloaded if the view is needed again). In this situation, you want to make sure that when the main view is disposed of you also relinquish ownership of any other outlets so that they too can be deallocated. For UIViewController, you can deal with this issue by overriding setView: as follows:
- (void)setView:(UIView *)newView {
if (newView == nil) {
self.uiElement = nil;
}
[super setView:aView];
}
Unfortunately this gives rise to a further issue. Because UIViewController currently implements its dealloc method using the setView: accessor method (rather than simply releasing the variable directly), self.anOutlet = nil will be called in dealloc as well as in response to a memory warning... This will lead to a crash in dealloc.
The remedy is to ensure that outlet variables are also set to nil in dealloc:
- (void)dealloc {
// release outlets and set variables to nil
[anOutlet release], anOutlet = nil;
[super dealloc];
}
I found what I was looking for in the Apple docs. In short you can set up your objects as properties that you release and retain (or just #property, #synthesize), but you don't have to for things like UILabels:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/chapter_3_section_4.html#//apple_ref/doc/uid/10000051i-CH4-SW18
The
[anOutlet release], anOutlet = nil;
Part is completely superfluous if you've written setView: correctly.
If you don’t release it on dealloc it will raise the memory footprint.
See more detail here with instrument ObjectAlloc graph
Related: Understanding reference counting with Cocoa / Objective C
You do alloc the label, in a sense, by creating it in IB.
What IB does, is look at your IBOutlets and how they are defined. If you have a class variable that IB is to assign a reference to some object, IB will send a retain message to that object for you.
If you are using properties, IB will make use of the property you have to set the value and not explicitly retain the value. Thus you would normally mark IBOutlet properties as retain:
#property (nonatomic, retain) UILabel *lblExample;
Thus in ether case (using properties or not) you should call release in your dealloc.
Any IBOutlet that is a subview of your Nib's main view does not need to be released, because they will be sent the autorelease message upon object creation. The only IBOutlet's you need to release in your dealloc are top level objects like controllers or other NSObject's. This is all mentioned in the Apple doc linked to above.
If you dont set the IBOutlet as a property but simply as a instance variable, you still must release it. This is because upon initWithNib, memory will be allocated for all IBOutlets. So this is one of the special cases you must release even though you haven't retained or alloc'd any memory in code.