I would like to know if there is any difference between calling [super viewDidUnload] before realeasing properties or after it.
Thank you!
self.webView = nil;
self.fullText = nil;
[super viewDidUnload];
or
[super viewDidUnload];
self.webView = nil;
self.fullText = nil;
This depends on what the superclass does in viewDidUnload. If it's just a standard UIViewController, either will do because -[UIViewController viewDidUnload] does nothing.
I never thought it mattered, but we just found a bug where the app crashed calling it first. The trend at my office has been to call it last, but the Apple template puts it first.
You can do what you want, but I will always call it last from now on.
This question is not fully answered. (And it's first hit when I google on this topic, so a complete answer would be useful to me and others.)
If the superclass DOES something in viewDidUnload, then what is the correct order for calling it in your class's viewDidUnload: before or after releasing properties?
For the record, it seems the consensus is to call the super method LAST:
-(void)viewDidUnload {
self.some_property = nil;
[super viewDidUnload];
}
This only matters if the superclass of your view actually does something in viewDidLoad. The default UIViewController doesn't do anything in viewDidLoad so if your view is a standard UIViewController then you can put [super viewDidLoad] anywhere in the viewDidLoad method. However, if super does something in viewDidLoad, then it does matter where you put [super viewDidLoad].
This is just like the dealloc method.
- (void)dealloc
{
[array release];
[super dealloc];
}
So I think we should call [super viewDidUnload] last.
Related
Ok, I'm having a lot of problems right now trying to get initWithCoder: to work right. I have a nib file that gets loaded, and in my app delegate, I call unarchiveWithFile: for the view controller that is associated with that nib, and now my app crashes. I can see that initWithCoder: is being called twice, presumably once from when awakeFromNib: is called, and then from when I call unarchiveWithFile: since the view controller conforms to NSCoding. But now either it crashes as soon as the view loads or when I press an IBOutlet. Any suggestions??
Edit: Here's the code for initWithCoder:
- (id)initWithCoder:(NSCoder *)coder {
[super initWithCoder:coder];
[[self mapView] addAnnotations:[[coder decodeObjectForKey:#"Annotations"] retain]];
return self;
}
All I'm doing is decoding an array of annotations for a map view, but somewhere along the line this method is being called twice and then it crashes.
Don't forget to put the nil check in your init methods. E.g. the method you posted would be more correct if you wrote it as:
- (id)initWithCoder:(NSCoder *)coder {
if (self = [super initWithCoder:coder]) {
[[self mapView] addAnnotations:[[coder decodeObjectForKey:#"Annotations"] retain]];
}
return self;
}
That's not the cause of your problem, however.
Is there are good reason for you unarchiving your view controller yourself? If you're not doing anything special, you can rely on the existing mechanisms to do it. The default implementation of init for a UIViewController looks for a nib with the same name as your view controller, and if it exists, it loads the nib (via initWithNibName).
If there is data which you need to archive in and out, it may be that it shouldn't be actually part of the UIViewController. Factor it out elsewhere perhaps?
you can try
- (id)initWithCoder:(NSCoder *)coder {
if(self == nil)
{
[super initWithCoder:coder];
[[self mapView] addAnnotations:[[coder decodeObjectForKey:#"Annotations"] retain]];
}
return self;
}
If I have a viewController setup as below:
#interface MapViewController : UIViewController <MKMapViewDelegate, CLLocationManagerDelegate> {
CLLocationManager *locationManager;
}
-(void)viewDidLoad {
[super viewDidLoad];
locationManager = [[CLLocationManager alloc] init];
}
when it comes to memory management should I be adding release to both viewDidUnload & dealloc?
-(void)viewDidUnload {
[locationManager release];
locationManager = nil;
[super viewDidUnload];
}
-(void)dealloc {
[locationManager release];
[super dealloc];
}
cheers Gary
EDIT:
[super dealloc] moved to bottom as per Deans kind comment.
Short answer :
Unless you are creating/retaining it in viewDidLoad (or a xib), don't release it in viewDidUnload.
Long answer :
viewDidUnload is used to release anything that you might have made when the view is created - this included things in viewDidLoad but also includes and IBOutlet properties that are created from inside a xib file. these should all be released and set to nil in viewDidUnload.
Anything else should just be released in dealloc.
The idea is that if viewDidUnload is called to free some memory, the view can be recreated again completely from your viewDidLoad method.
In viewDidUnload you should be setting your IBOutlet properties to nil and anything that is initialized in viewDidLoad.
Remember that if the phone is low on memory, your view will be unloaded if it isn't on-screen. Next time your view is loaded again, new views will be connected to the IBOutlets and viewDidLoad will be called again. So you should set the outlet properties to nil in viewDidUnload to reduce the memory footprint.
The guy is doing a [object release] before doing the self.object = nil;
Is the first release for nothing ? In the Apple documentation, they simply affect nil to the variable... what is right?
I'm dealing with viewDidUnload and dealloc methods and I've founded a problem when calling [super dealloc]; in parent view controller.
I have a lot of view controllers with custom code which I have putted outside on a parent view controller. So, when defining my view controllers I set a reference to the super class:
#interface LoginViewController : AbstractViewController
Then, at the dealloc method I call the AbstractViewController dealloc method:
//(Login View Controller code)
- (void)dealloc {
[user release];
[passwd release];
[super dealloc];
}
[super dealloc] execute the following code:
//(Abstract View Controller code)
- (void)dealloc {
[dbUtils release];
[loadingView release];
[super dealloc];
}
If I simulate a memory warning on iPhone Simulator, the following exception is thrown:
2010-03-03 11:27:45.805 MyApp[71563:40b] Received simulated memory warning.
2010-03-03 11:27:45.808 MyApp[71563:40b] *** -[LoginViewController isViewLoaded]: message sent to deallocated instance 0x13b51b0
kill
quit
However, if I comment the [super dealloc] line in AbstractViewController the exception is not thrown and my app still running.
Thank you for your help once again!
It looks like you're freeing your view controller but then trying to use it again. When you free your view controller because of the memory warning, remember to set the pointer to nil so you don't accidentally use it again. i.e. something like
[myLoginViewController release]; //!< Triggers the dealloc call
myLoginController = nil; //!< Makes sure we never use it again
or, if myLoginViewController is a property you can do this in a neater way :
self.myLoginViewController = nil;
Hope that helps,
Sam
Notice -didReceiveMemoryWarning does not trigger -dealloc, it triggers -viewDidUnload. So I guess it is your implementation of -viewDidUnload that does something wrong that causes the controller's final retention to be released so -dealloc is called. I've just encountered this problem in my code which is caused by a retain recycle that is released in -viewDidUnload.
This happened to me and took a while to figure out. One of the delegates was trying to send a message because the delegate was self and it was a strong reference. when I made it weak it seems to have fixed it.
I am having a uiviewcontroller instance and when I am releasing it the dealloc method of it is called.
I have released some objects in dealloc method of that uiviewcontroller.
If I comment [super dealloc] the app is working fine but if don't it is crashing.
I think there is no problem with the releases that I am doing in that method, but if I do [super dealloc] it is crashing.
Can any one help me out with this?
Hard to tell from your post without more information, but does your dealloc method look like this?
- (void)dealloc {
[super dealloc];
self.someProperty = nil;
}
Because if it does, you're calling a setter method on a deallocated instance. You should always call [super dealloc] last:
- (void)dealloc {
self.someProperty = nil;
[super dealloc];
}
Not sure if that helps. Try posting what your dealloc method looks like if not. Hard to troubleshoot in the dark.
It's not possible to help you without more information. The code you described is perfectly fine. The problem is in some other part of your app.
You probably access the view controller after releasing it, so the problem is not the [super dealloc] but any other place in you application that accesses the view controller.
Maybe you are releasing the controller in the wrong place. That could be why your [super dealloc] in your ViewController.m is crashing
You shouldn't called [viewController release] until you want that controller to die. For example, if you have an application with just a viewcontroller you must not release it until the application ends. This is because that controller needs to stay alive all the time to control the view. If you have in your ApplicationDelegate something like this, it will crash:
- (void)applicationDidFinishLaunching:(UIApplication *)application {
UIViewController *controller = [[UIViewController alloc] init];
[window addSubview:controller.view];
[controller release]; //this will crash
}
Instead of that you should place your viewcontroller in the header file (.h) and release it in the dealloc method:
- (void)dealloc {
[controller release];
[window release];
[super dealloc];
}
I hope this helps.
correct example:
- (void)dealloc {
[viewController release];
[window release];
[super dealloc];
}
wrong example:
- (void)dealloc {
[super dealloc];
[viewController release];
[window release];
}
Althoug in alsmost all other cases when overriding a method I would first call the super's method implementation, in this case apple always calls [super dealloc] in the end. Why?
Its just a guideline. You can call other instructions after [super dealloc]. however you can not access variables of the superclass anymore because they are released when you call [super dealloc]. It is always safe to call the superclass in the last line.
Also KVO and depended (triggered) keys can produce side effects if they are depended of already released member variables.
I don't know anything about programming for the iPhone, but I would assume that it is for the same reason that destructors need to be called in reverse order. You want to make sure that all your 'garbage' is cleaned up before calling your superclass. If you do it the other way around things can get messy. For instance, if your destructor needs to access memory that the super destructor has already freed:
class X {
private Map foo;
function __construct() {
foo = new Map();
}
function __destruct() {
foo.free;
}
}
class Y extends X {
function __construct() {
super.__construct();
map.put("foo", 42);
}
function __destruct() {
super.__destruct();
if (map.containsKey("foo")) { // boooooooooom!
doSomething();
}
}
}
You may not encounter this problem in your code, because "you know what you're doing", but it is a safer and overall better practice not to do such things.
[super dealloc] is freeing up the memory used by your object, including the pointers to viewController and window. Referring to variables after you've freed them is hazardous at best.
See this answer.
Here is actual example where [super dealloc] must be last, otherwise the call to removeFromRunLoop will cause crash. I'm not sure what happens inside NSOutputStream's removeFromRunLoop, but it seems to access 'self' in this case.
Setup:
[outputStream setDelegate:self];
[outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];
Dealloc:
- (void)dealloc {
if (outputStream) {
[outputStream close];
[outputStream removeFromRunLoop:[NSRunLoop currentRunLoop]
forMode:NSDefaultRunLoopMode];
[outputStream release];
outputStream = nil;
}
delegate = nil;
[super dealloc]; // must be last!
}
You practically almost have [super dealloc] at the end because it frees up the variables of the superclass and they can no longer be accessed.
One exception is if you have a subclass of UITableViewController that is using another class as its table view delegate. In that case you have to release the table view delegate after [super dealloc] because the table view is referencing the table view delegate and the table view has to be released first.
[to the last post] Wouldn't the tableView referencing the delegate be responsible for releasing it's own delegate? I would think it's retained it when set (so you could release or autorelease it) and it would take care of itself?
As for the OP question, I will always call super first if I'm constructing and call super last if I'm destructing. I think of it as "I want to have super build what it wants so I can build on that, and I want super to tear down last after I clean up after myself." Virtually all the calls I use are constructing though, except dealloc, so that's why you would see it last in my dealloc code always.