In my app delegate I have one object that I need to use in some different 3 viewControllers.
To use it I do in the interface
NewsPadAppDelegateiPad *delegate;
and in the implementation I do
delegate = (NewsPadAppDelegateiPad *)[[UIApplication sharedApplication] delegate];
[delegate.reader setDelegate:self];
....
[delegate.reader doSomthing];
When In my dealloc method I do
[delegate release];
delegate=nil;
I receive the error
[CFString release]: message sent to deallocated instance 0x9d4fac0
I really need to release that?
In general, you should not retain your delegates: this lets you avoid retain cycles - situations when two or more objects retain each other in a cycle, preventing the whole group from being deallocated.
This looks to be a pre-ARC code, so you should simply avoid retaining and releasing your delegate.
In ARC code you should declare your delegates __weak unless you have specific reasons to use strong references (specifically, you retain your delegate when you want to own the delegating object; this is very rare - in fact, it's usually the other way around).
Here is a good discussion of the topic on why delegates are not usually retained.
According to Cocoa's memory management name convention, you don't own the object so you don't release it. It will be released for you when it goes out of scope.
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.
I am new to iphone and I want to know when does -(void) dealloc method call. I know it is used to release objects but can we release any kind of object using dealloc method? And is it necessry to add this method and why we write [suped dealloc] in dealooc method?
share your views.
Here is the explanation straight from APPLE's Docs
The NSObject class defines a method, dealloc, that is invoked
automatically when an object has no owners and its memory is
reclaimed—in Cocoa terminology it is “freed” or “deallocated.”.
Important
Never invoke another object’s dealloc method directly.
Here is the answer why we call [super dealloc]?
You must invoke the superclass’s implementation at the end of your
implementation. You should not tie management of system resources to
object lifetimes
When an application terminates, objects may not be sent a dealloc
message. Because 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.
You Can release object those which is allocted, copy, or retain by you this is simple to understand. You can not release object those are not allocating by you means autorelease object, which ios detect for no more use in memory ,that time autorelease pool drain that time those object released from memory automatically.
And object dealloc method called when object retain count becomes zero.
You never send a dealloc message directly. Instead, an object’s dealloc method is invoked indirectly through the release NSObject protocol method (if the release message results in the receiver's retain count becoming 0). See Memory Management Programming Guide for more details on the use of these methods.
Subclasses must implement their own versions of dealloc to allow the release of any additional memory consumed by the object—such as dynamically allocated storage for data or object instance variables owned by the deallocated object. After performing the class-specific deallocation, the subclass method should incorporate superclass versions of dealloc through a message to super:
Refer this Link
I'm using the following code many times in my app (especially to manage a NavigationController):
MyAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];
When should I release it ?
Thx for helping,
Stephane
Don't. Never release your application delegate - it is managed automatically by the OS.
If you look in your app's main.m file, you'll see some code that initializes an instance of UIApplication that represents your app - it is its responsibility to manage the application delegate's lifecycle, not your responsibility.
EDIT as #Goz points out, you should release it if at some point you retain it. However, since the application object (and therefore, by extension its delegate) is guaranteed to remain in scope for the life of the app (unless you go messing with it), it's far better to simply not do any memory management on the delegate, as this avoids the possibility of accidental over-release or other related issues.
Short answer: never ever release your application delegate.
Explanation:
It often helps me how to address mem-mgmt issues, when I check how the things are declared. Take a look how delegate property is declared for UIApplication:
#property(nonatomic,assign) id<UIApplicationDelegate> delegate;
As you can see, it is assigned property meaning all mem-mgmt done here is just assigning pointers for an instance variable. It means calling release on your application delegate will result in -dealloc method being executed for your MyAppDelegate. Go and try this in debugger and you'll see that your application will receive EXC_BAD_ACCESS - i.e. it will crash.
EDIT: However, as Goz suggests, you can call retain and then release. But in the first place, it doesn't make sense to do this retain/release thing on app delegate.
I have a property defined as:
#property(nonatomic, retain) UITableView *settingsTableView;
Then in my viewDidLoad method I have:
self.settingsTableView = [[[UITableView alloc] initWithFrame:tableFrame style:UITableViewStyleGrouped] autorelease];
[self.view addSubview:self.settingsTableView];
[self.settingsTableView release];
Then in the dealloc method of the view controller I have:
[settingsTableView release];
When I attempt to do the release from within the dealloc I am getting a "message sent to deallocated instance". I am starting to second guess myself, anybody see anything stupid in what I've done?
Really appreciate the help on this one!
you're calling release on an object you've already autoreleased. Just get rid of the line
[self.settingsTableView release];
and you should be good.
Note that you should keep the release in the dealloc method, since the property calls retain for you, but not release.
Two things. First, you're over-releasing the table view in the first place: the autorelease call negates the need for a manual release afterwards.
Also, in general, what you release in -dealloc are things that you created in -init, -initWithCoder:, or whatever, not loadView or -viewDidLoad. In this case, the method you're looking for is -viewDidUnload; you just have to set self.settingsTableView to nil in that method, and the property setter will handle releasing it if necessary.
Here is the change you need to make.
self.settingsTableView = [[[UITableView alloc] initWithFrame:tableFrame style:UITableViewStyleGrouped] autorelease];
[self.view addSubview:self.settingsTableView];
[self.settingsTableView release];
//^^^ This line is bad no need to release this value until dealloc
//if it is defined as retain or copy
Seems obvious. You have already released with
[self.settingsTableView release];
So why release it again in the dealloc?
I believe the problem is related to your use of autorelease when you are allocating and initializing the UITableView.
You also might have a problem with releasing the settingsTableView right after you use it, vs. in the dealloc method. Anytime you alloc/init an object, you should only release it once.
If you use autorelease, the rules are a little different, so I'd recommend reading up on that again. Also, when you pass objects that you've created off to other things, they may take complete or shared ownership of the object by retaining it, meaning that you may or may not need to release it yourself anymore. The documentation for that should be on the method you're calling (like addSubView).
I am wondering what the difference is between release and dealloc? After reading, the memory management rules (See below)., I am thinking most of the time I will be using release. However, I wanted to know what to do for properties.
#property(retain)....
I have been using dealloc but after reading this article I am not sure that is correct.
You take ownership of an object if you create it using a method whose name begins with “alloc” or “new” or contains “copy” (for example, alloc, newObject, or mutableCopy), or if you send it a retain message. You are responsible for relinquishing ownership of objects you own using release or autorelease. Any other time you receive an object, you must not release it.
You should never call dealloc on anything other than super.
The only time you will be calling dealloc is in the dealloc method of a custom inherited object, and it will be [super dealloc].
When the retain count of an object goes down to zero, dealloc will automatically be called for you, so in order to manage memory properly, you need to call retain and release when appropriate.
If this isn't clear to you or you'd like details about how memory is managed in Cocoa, you should read the Memory Management Programing Guide.
You never call dealloc directly. It is invoked by the system when the retainCount of the object goes to 0. Every time you do a retain, the retainCount is incremented with 1. Every time you do a release, it gets decremented. This way, by balancing your retains and releases, you ensure than when the retainCount gets to 0, dealloc will be automatically called, and your object freed.
As Ben S noted, the only time and place you would call dealloc is in in the dealloc method of an inherited object.
When you use #property(retain) and then #synthesize to generate the property code, you do not need to do any manual memory management on the property. The other answers are correct in that you shouldn't be using dealloc except in your own override of a parent class dealloc.