When should I release all the memory I allocated in my program?
Because I only have a viewDidLoad method where I do my business. Should I leave dealloc empty and cleanup only in viewDidUnload?
'dealloc' is used when the object is ready to be freed (i.e., when retain count of the object becomes 0). And viewDidUnload is called when the view is unloaded, but it may not be freed immediately as the reference of the UIViewController is still stored by some other objects.
my personal preference is, for ojbects created by 'init', they are freed by 'dealloc', for objects created by 'viewDidLoad', they are freed by 'viewDidUnload'.
As the documentation of -viewDidUnload says:
It is called during low-memory
conditions when the view controller
needs to release its view and any
objects associated with that view to
free up memory. Because view
controllers often store references to
views and other view-related objects,
you should use this method to
relinquish ownership in those objects
so that the memory for them can be
reclaimed. You should do this only for
objects that you can easily recreate
later, either in your viewDidLoad
method or from other parts of your
application. You should not use this
method to release user data or any
other information that cannot be
easily recreated.
Typically, a view controller stores
references to objects using an outlet,
which is a variable or property that
includes the IBOutlet keyword and is
configured using Interface Builder. A
view controller may also store
pointers to objects that it creates
programmatically, such as in the
viewDidLoad method. The preferred way
to relinquish ownership of any object
(including those in outlets) is to use
the corresponding accessor method to
set the value of the object to nil.
However, if you do not have an
accessor method for a given object,
you may have to release the object
explicitly.
There is no mention -viewDidUnload will call in -dealloc, you shouldn't rely on it.
Related
Using xcode 4.2 for iPhone app, without ARC ---
When I create an outlet using the interface builder xcode adds two lines of code to my viewController. One in viewDidUnload: -- [self setMyOutlet:nil] and second in dealloc -- [myOutlet release].
I understand the latter (the release). But why set the outlet to nil in viewDidUnload. Doesn't viewDidUnload get called before dealloc and won't setting the outlet to nil negate the release operation in dealloc? Setting to nil makes sense I would think for building a Mac application which is using garbage collection -- but it doesn't make sense for an iPhone app.
Why does the interface builder do this? Should I delete the lines which set the outlets to nil?
viewDidUnload may be called and may be not called. It depends on the current memory usage. dealloc is a place where you should clean all your properties (like arrays, custom objects). In viewDidUnload you clean views and perhaps objects created to support the view. viewDidUnload mean that your view is unloaded (but not whole view controller) and it may be created and loaded again (in viewDidLoad, of course) in the future.
Why to nil - Objective-C Difference between setting nil and
releasing
Understanding How Views Are Loaded and
Unloaded
viewDidUnload is not called everytime before a dealloc, see what the apple docs say..
When a low-memory condition occurs and the current view controller’s
views are not needed, the system may opt to remove those views from
memory. This method is called after the view controller’s view has
been released and is your chance to perform any final cleanup. If your
view controller stores separate references to the view or its
subviews, you should use this method to release those references. You
can also use this method to remove references to any objects that you
created to support the view but that are no longer needed now that the
view is gone. You should not use this method to release user data or
any other information that cannot be easily recreated.
so the idea behind it is too release any unwanted objects which can be created easily.
Now coming to the part where it sets the properties to nil.. it does so because this way you release all the memory and set the objects to nil (thus bringing your down your memory usage) and after this if a dealloc is called your app will not crash as in objective-c you can send release messages to nil objects..
I would advise you to read the apple ViewController Programming Guide , it will clear a lot of your questions.... hoping this clears some of the air.. :D
If I am using a block when making an asynchronous operation and the block references objects and properties of the view controller, does the block retain them and thereby making the view controller not get deallocated if the user leaves the view controller before the async operation ends?
Yes. Blocks are Objective-C objects and will retain any referenced objects. You can ask them not to, of course.
See: http://thirdcog.eu/pwcblocks/#objcblocks
Subviews added to a view are automatically retained by the view. Suppose you want to have a separate pointer to the same subview so you don't need to constantly retrieve it via its tag.
What type of #property is necessary for such a case? I assume that setting the property to retain is not a good idea since the main view is already retaining it? Should it be assign?
Or, is using #property entirely unnecessary here unless you plan to re-assign it later or refer to it with dot notation?
You can use either retain or assign.
Of course, if you use retain, you have to set the property to nil or release its object in viewDidUnload and dealloc.
The reason some people prefer retain is because it means the property is still valid in viewDidUnload. So if you have other cleanup to do, and that cleanup requires the view to still exist, you can do it in viewDidUnload.
If you use assign, you don't have to set the property to nil in viewDidUnload and dealloc (though it would be good practice). However, by the time you receive viewDidUnload, the view has already been released, so you can't use it at that point for other cleanup. Instead you have to override didReceiveMemoryWarning to do the cleanup before calling [super didReceiveMemoryWarning].
In iOS 5.0, you can do the cleanup in viewWillUnload instead of overriding didReceiveMemoryWarning.
Consider these two things:
There's no problem with retaining an object several times provided that each retain is balanced with release. With respect to properties, this just means that you should set your property to nil when you're done with it.
The basic idea behind memory management in Objective-C is that you worry about retaining the objects that you're using and let other objects worry about the objects that they're using.
Considering these, I'd advocate using retain. If you rely on he fact that a view retains its subviews, you've suddenly made your code dependant on external behavior. I'm not saying that UIView is likely to stop retaining its subviews, but if you keep a non-retained reference to a subview and later remove that subview from its superview you're code is likely to crash.
Some folks do use assign for outlets pointing to subviews when they know those subviews will never be removed. Personally, I don't see the point of relying on another object to retain something for you when retaining that thing yourself is so simple and cheap.
The Apple template provides this comment in the viewDidUnload:
// Release any retained subviews of the main view.
// e.g. self.myOutlet = nil;
So I typically set IB Outlets to nil in viewDidUnload then release them in dealloc. The question is, all my other retained ivar objects, some of which are views that were added programmatically, while others are data models, should they also be dealt with in these two methods? If not, why not?
from this answer here i gather that only view-related objects should go in viewDidUnload as =nil statements, which should probably include non-IB Outlet retained views, correct? Then, all other objects, included data models, should go in dealloc as release statements. Is this the normal practice?
viewDidUnload is called as a result of a low memory condition to unload the view for a view controller that is not currently visible. At this point the view object of the view controller has been released which means all the objects that are subviews of viewController.view have been released, but they are not deallocated if you are retaining them in your ivars.
You should release any object that will be recreated when the view is loaded again or things you can easily recreate as needed. The next time the view is used the view will be recreated either from the NIB or by calling loadView so all those things you release will be recreated.
When your view comes from a NIB all the view objects specified in the NIB are created and added as subviews of the view controller's view. Any ivars with IBOutlets are also connected to those subviews so that you also "own" those objects (you have a retain on them). You need to release those ivars so that they will actually get dealloc'd.
When your view is created programatically in loadView you should also release those object retained by your ivars that will be recreated in loadView the next time the view loads.
Same for anything you create in viewDidLoad (or viewWillAppear or elsewhere), such as data models, if you can recreate it "easily" later when the view loads again or when the object is needed then it should be released in viewDidLoad to reduce memory usage. Actually for non-view items, like a data model, I would release it in didReceiveMemoryWarning instead.
Assigning nil to a retained property using the setter causes a release to be sent to them, when you write self.myOutlet = nil you are invoking the setter method which is implemented something like this:
-(void)setMyOutlet:(id)newObject
{
[newObject retain]; // does nothing if newObject is nil
[myOutlet release];
myOutlet = newObject;
}
Is there any way to detect when an NSView will be dealloc'ed?
The reason is, I have some simple delegates (such as an NSTextField delegate that handles -control:textView:doCommandBySelector: to allow the return/tab keys to be entered). I'd like to just stick this delegate object in the nib, wire up the NSTextField's delegate connection and have it work.
And it does work, but the delegate is never released even after the NSTextField it is linked to is released, so the delegate object leaks.
I'd like the delegate object to be able to detect when the NSTextField is dealloc'ed, but I can't think of any way to do this, which leaves me having to store a separate link to the delegate object from some other controller and manually release it at some point which is very much less than ideal. Any ideas?
I've had a good look for this previously, and there doesn't appear to be any way to observe when an object is deallocated. I have seen one way to do it in a weak pointer class, but it involves isa swizzling, which can get nasty. Here is the website: http://www.cocoadev.com/index.pl?WeakPointers
Objects that are created from a nib file should be deallocated when the owner of the nib is deallocated, unless they are retained elsewhere. For example, when an NSWindowController is deallocated it will release any objects that were created when the nib was loaded. If your delegate objects aren't being deallocated, maybe it's because they are retained elsewhere, or there is a retain cycle.