Where is the best place to invoke removeObserver:name:object: since the dealloc method does not always be executed as mentioned in NSObject class reference ??
If you're referring to this note:
Important: Note that when an application terminates, objects may not be sent a dealloc message since the process’s memory is automatically cleared on exit—it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods.
It says dealloc is typically not guaranteed to be called only on application termination. So even if dealloc isn't called, the resources used by your application will still be cleared by the OS. That means all your objects will be gone anyway because your application isn't there anymore.
Therefore, the best place to remove a notification observer from the notification center is still within the observer's dealloc method.
Related
I have created an object using alloc/init method, and after I release it -dealloc should be called immediately as per documentation. I set a breakpoint on -dealloc method but it isn't hit, and my -dealloc method is not called.
Please tell me what is the reason behind that, and what is use of dealloc method in objective c ?
The -dealloc method is not always called when you expect it to be called. The runtime might also have issued a -retain on your object for internal reasons.
It's also possible that you have (directly or indirectly) caused an extra -retain to be issued. If the retains/allocs and releases are not balanced, you'll never see -dealloc called. It helps to turn on the Static Analyzer, to make sure your calls balance.
Just follow the memory management rules, don't second guess the runtime, and let the memory management system do its job.
The answers to When does dealloc method call? may help you understand what you're seeing.
because it still has reference. that means its reference count not reached to zero. i don't know your code, where it is referencing. but it is not calling that means somehow still it has reference. it may be because of strong relationship or parent-child relationship
all Objective-C objects are allocated on the heap, so they must
therefore be deallocated somewhere if you are not to run out of
resources.
This gave way to the reference counting method, which is still used
today: each object keeps count of any references held to it. If you
receive an object and you want to keep it, you retain that object,
incrementing its reference count. When you are done with it, you
release it, which decrements its reference count. Once that count
reaches zero, it is inferred that no one is referencing the object and
it is automatically deallocated using the -dealloc method.
Additionally, an object could be told to “release at some point in the
(hopefully) near future” using autorelease pools. The idea is that
somewhere on the stack (typically at the start of a thread or while
responding to input events) an autorelease pool is created and pushed
onto a stack. Any object can then be sent an -autorelease message, and
it is assigned to that pool.
When the pool object is deallocated, it simply sends a -release
message to all its assigned objects. That way, any objects that are no
longer used (i.e. they haven’t been explicitly retained) are then
deallocated.
The dealloc is called (at more cases) whenever your object is released. You can't directly call this method.
#interface myViewController:UIViewController
{
NSString *myStr;
}
#end
Here the dealloc method in the #implementation of myViewController will be called (at most cases) when the myViewController object is released, not when myStr is released.
Although you don't have to use if you ARC.
My Question is When the dealloc method will cal before the application termination, If it happens , When the application terminates all the memory of the objects and application will be removed from memory, then what is the use of writing dealloc method?
This is a general question about memory management. You use dealloc in Objective-C, free in C etc. to clean the memory allocated for the variables that are no longer in use. When the application terminates of course all of the memory allocated by the application will be released. However, if your application keeps allocating memory as it runs, and if the user runs the application for long enough, unless you release unused memory, the device's memory would get eventually used up. This is why you need to use dealloc.
The dealloc method describes how the object will be released. When an object is being deallocated unless you override the dealloc method only the object's pointer will be released. Therefore, in order to release properties and fields in your object you need to manually release them in your dealloc method.
I do not clean up singleton objects that live the life of the application in the dealloc. Is there any reason I should?
- (void) dealloc
{
// never deallocs
[super dealloc];
}
I'm kind of assuming that the iOS has me sufficiently walled off to clean all of my app's memory up when it ends. Is that right?
Yes, when your app is terminated, your app's virtual memory address space will be completely wiped/freed. You can fill out -dealloc if you want, but it will never get called, so the only advantage to doing so is that if you decide to make your object a non-singleton down the track, you've got the dealloc method there already.
One thing to keep in mind is that any singleton (which will exist for the entire life of your app) that has any kind of cache that could reach a large size should register for the UIApplicationDidReceiveMemoryWarningNotification, and reduce or flush the cache as appropriate when a memory warning occurs.
I use code like the following (inside my appController.m for example) to do some cleanup when my application terminates...
- (void) dealloc {
[myObject release]; // myObject 's dealloc will not be called either !!!
[arraySMSs release];
[super dealloc];
}
This method never get called when the app quits! Why ? Is there a better place to do my clean up ? The fact that is not called addresses memory-leak issues ? Or the OS does take care of clean up ?
Thank you...
There is no reason for the system to ensure that every object is individually deallocated upon application termination.
Doing so is just a waste of CPU cycles and a waste of the user's time.
When an app is terminated, all resources used by that app are reclaimed by the system in an entirely automatic and unavoidable fashion.
If you need something to happen at app termination, use the application delegate's hooks for doing so. But don't rely on that. A user may force reboot a device or force quit an application at whim.
Here's the quote from NSObject Reference:
"Important: Note that when an application terminates, objects may not be sent a dealloc message since the process’s memory is automatically cleared on exit—it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods."
It pretty much confirms what many people have said.
nice question, i was confused too.
now i got this:
Said that there's no object managed by our custom code that owes the appDelegate class itself, we don't really need to worry to "release" its instance.
UIApplication is the only class that retain it, but we don't owe it.
But, for academic discussion or if there's any purpose i don't know at the moment,
when you wanna test the dealloc in your appDelegate class:
applicationWillTerminate is the right place to know if your app is going to quit.
- (void)applicationWillTerminate:(UIApplication *)application
{
// Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
[UIApplication sharedApplication].delegate = nil;
// after this, the dealloc method of our appDelegate class will be called
}
What makes you think dealloc is not being called? Have you run this is the debugger? Please see this question for why you won't necessarily be able to call NSLog in the dealloc method: when is dealloc executed?
I have a tableviewcontroller where I populate some data from a sqlite db and for each row, I download a file from a http server and cache it locally. I cache it only when the "detailsview" is opened. And the detailsview responds back to this table through a delegate after the file download is complete.
But, when this tableview itself is popped out of the navicontroller., the call to delegate fails with a EXEC_BAD_ACCESS
I called [_delegate retain] in the setDelegate of the details view and everything works fine, but I'm not sure whether this will leak memory...
Could anyone advise?
Your delegate is getting released prematurely, and sending a message to an invalid object will call EXEC_BAD_ACCESS. Retaining it will fix the problem, but in general it's good practice to not have an object retain its delegate, as there is the potential for retain cycles, so you might need to rethink your structure. If you're releasing your delegate when the view is dealloc'ed, you need to remove it unless you're also retaining the delegate in setDelegate:.
Generally, delegates are not retained to avoid retain cycles. If the delegate may be released before you, then it is the responsibility of the delegate to clear your reference before it is finished being deallocated (eg in its dealloc).
However, if any property is set to "retain" or "copy", then you would retain/copy it in the setter (or use #synthesized setters which will do it for you), and release it in dealloc to avoid leaking. As said above though, that may lead to a retain cycle so that neither object ever gets deallocated.
I would suggest you turn on some memory debugging with environment variables NSZombieEnabled and NSAutoreleaseFreedObjectCheckEnabled and see if it tells you which object is being over released.