So far I have been removing observers (notifications or KVO) in the dealloc. Since dealloc is gone in ARC, what's the recommended way to do this?
-dealloc is not gone under ARC. The ivar-releasing and super-calling aspects are handled automatically, allowing you to omit it if that's all you were going to do, but you should still implement it for other things if it makes sense to do so.
Related
NSNotificationCenter is known not to retain/release the observers. It makes sense, and I also have experienced related issue.
Anyway today I realized that I really am not sure on this. The official documentation doesn't say anything about ref-counting stuffs.
Though its discussion section says that we have to unregister the observer before it deallocates, but it doesn't mean the center will not retain them. And deallocation timing can become different by the behavior of the center.
Then, I couldn't find anything from the documentation.
But in practice, we already know the add/remove observer method doesn't retain the observer by experience. Unretained reference is very exceptional behavior which may cause serious bug, then I believe that there should be an explicit mention on this.
Where is it?
No, observers are not retained. That's why when you make an object an observer, you must make sure that it stops observing in its dealloc method. Logically, an observed object should know nothing about the observer, shouldn't care about observers, and therefore shouldn't hold a strong reference to observers.
Can someone tell me what would actually happen if you override the dealloc method in Objective-C? As in would it crash or would it just start leaking memory all over the place. I've been wondering what would happen and why it is necessary to prevent the programmer from using dealloc directly.
And in what case would you had to do something like this?
EDIT: Sorry guys for not being clear. I was mainly talking in terms or ARC type coding.
Overriding -dealloc is an extremely common thing to do in non-ARC code. In fact, you'd be hard-pressed to find a class that doesn't override it.
The key thing to remember, though, is that every single override of -dealloc always ends with a call to [super dealloc].
Of course, in ARC code, overriding -dealloc is far less common. And if you do override it, you don't call [super dealloc], because the compiler will insert that for you. But remember, this is only true under ARC.
Before ARC overriding the dealloc method was very common, you were releasing the ivars the deallocated instance owned. Now, with ARC, is less common, however, you may have to do it in some special cases, like when you de-register an instance from observing with NSNotificationCenter.
The rule you talk about was not to call dealloc directly (not override), that would have usually led to a crash since you were bypassing Cocoa's internal reference counting system.
Edit: Based on your edit, if you call [super dealloc] under ARC, you'll get a compile time error. And if there was no error, it would have probably lead to duplicating the dealloc call, which would have made your program crash.
I'm using ARC. Will ARC automatically release all the properties in dealloc? Is it necessary to manual set all public properties and private field to nil? Are there any good pattern to follow?
Under ARC, the pattern is... don't do anything in dealloc, or even implement it. ARC takes care of your properties and instance variables for you.
The only exception is that dealloc is a good place to unregister for notifications, if your object has registered for any.
Good question. When using ARC the compiler will implement a dealloc method for you and will handle implicitly the release of your instance variables and properties.
You may still need a custom -dealloc if your class needs to do anything other than releasing memory (e.g unregister for notifications like jrturton mentioned).
You can get a good grasp of what's you need to consider when transitioning to ARC in those Apple official notes.
We all know an object's properties should be released through its dealloc method, but often for objects with many properties this can be pretty cumbersome. It's kind of a headache especially when adding or removing new properties to remember to go back to dealloc and add and remove release calls.
Is there any method of releasing all of an object's properties generically? I wasn't able to find anything while looking through the docs, but could this be done through reflection if it's not already implemented?
I guess another simple option might be to just place all the properties in an array or other container object and always just release the container. Any other options?
I saw one once (and even used it). It involves using the Objective-C Runtime to loop through the properties of a class, check which ones have either a retain or copy flag, and then set them to nil. Then, your -dealloc implementation can be reduced to something like [self cleanupProperties] or something.
The long story short, however, I've stopped using that because of really wacky problems that I can't explain. I don't know for sure that this is what caused it, but it just seems clever enough that it would have some sort of nasty, unforeseen side-effects.
So, in answer to your question: it's definitely possible, but I'd advise you don't. Use garbage collection if possible! :)
Unless you can turn on garbage collection you're pretty much down to two options. As you suggested you could stuff all the property references into a single NSDictionary (which you would release in -dealloc). Otherwise you're stuck with the way it's usually done.
You can see more about garbage collection in Objective-C 2.0 here.
I inherited an iPhone app at work and I'm new to Objective-C so I don't have my bearings just yet. I encountered code similar to this:
- (void) dealloc {
[[StaticObject sharedObject] showSomeDialog];
[super dealloc];
}
I know this is frowned upon in other languages. My spider sense is going crazy looking at that code.
Is this a common Objective-C idiom? Or do I have a crappy codebase to fix?
You should not put UI code in a -dealloc. General rule of thumb, only use -dealloc to clean up what you've done: release objects, remove observers, etc.
Consider what would happen if this object lived on a thread other than the main thread... now you'd have UI code running on the non-main thread, which is a bad thing.
You can do such thing for some debugging reasons. But I don't think you should ever do anything like this!
This means a dialog is prompted when an object is being deallocated. So if you need any mechanism to show a dialog at a certain time don't make it depended on an object being deallocated.
In the dealloc method you should really just release all objects retained by the deallocated object. And not doing some fancy application features.