A quick question regarding Managed Objects.
I created an Array with Managed Objects (in Object 1: TableViewConbtroller), and pass one of those objects to another class/object (object 2: TableCell).
The original array should still be retained in the original caller class.
Then Object 2 is released, does that mean that that particular item in the array is released as well, as the reference to it in Object 2 was released?
I am trying to better understand how to work with ManagedObjects as I get 'Object was released' errors.
[EDIT]
After some experimenting I came across the following scenario:
I have the main AppDelegate.
In a different class I create an AppDelegate to obtain the ManagedObjectContext.
appDelegate = (iDomsAppDelegate *)[[UIApplication sharedApplication] delegate];
[self setContext:[appDelegate managedObjectContext]];
When the class is finished, and I release it, the variable in the class 'appDelegate' is also released. But then the ManagedObjectContext is closed, and obvious any future attempt to use it will cause a crash. So should I leave the appDelegate unreleased?
This comes to the same question as the above about when and how to release in those situations where an objects is used from another class. I think a way of putting it is, how to know when you own an object and when not.
The UIApplication retains your app delegate, so releasing it in your view controller's dealloc method will not deallocate the app delegate.
Related
I am using Xcode 4.3 and need to know the parent view controller of the current view.
I am also using storyboard.
self.parentViewController always returns nil.
I saw different answers to save the parent view controller in AppDelegate class as a property. E.g., To create a variable: UIViewController parentViewController in AppDelegate and in the code write:
appDelegate.parentViewController = self;
I am afraid that it will consume memory - as this is a heavy object.
What is the best approach to know aretnViewController when using story board?
Whether or not an object is "heavy" does not matter as long as you store only a reference to it (in your case in the application delegate). Creating a second object would make a difference, but the line
appDelegate.parentViewController = self;
does not do that, it merely stores a reference to the object.
I know that this does not answer your direct question, but I think you should go ahead with the "store a reference in the app delegate" approach.
I'm really scratchng my head trying to work out where my managed object context is vanishing to.
I'm originally instantiating it within my app delegate and then passing it into a retained property within an NSWindowController as such:
self.TPWC = [[TestPanelWindowController alloc] initWithWindowNibName:#"TestPanel"];
self.TPWC.managedObjectContext = self.managedObjectContext;
self.TPWC.persistentStoreCoordinator = self.persistentStoreCoordinator;
[TPWC.window makeKeyAndOrderFront:nil];
I've then got a button that should instantiate an NSManagedObject and insert it into the managed object context like this:
NSManagedObject *newInstanceOfSomeEntity =
[NSEntityDescription insertNewObjectForEntityForName:#"SomeEntity"
inManagedObjectContext:self.managedObjectContext];
At this point, self.managedObjectContext has somehow become nil.
I've inserted a breakpoint into windowDidLoad and I can confirm that at that point, we do have a valid instance of an NSManagedObjectContext, but it's somehow become nil in between viewDidLoad and then trying to insert a managed object.
I've tried creating a custom initialiser to set the NSManagedObjectContext but it's still becoming nil.
Core Data is quite new to me and I'm struggling to understand what's going wrong.
This is not a direct answer to why you're seeing your context disappear, but it could still fix your problem:
From an architecture standpoint, you really shouldn't be passing around the managed object context between objects, especially UI objects.
Instead you should have a global singleton class that instantiates the managed object context (along with the coordinator and persistent store, probably), and then provide access to it via a public property. Then, from your window controller, you would just access it from the singleton object.
(A side note if you're using multi-threading, be careful of accessing and using the same context from different threads.)
I'm getting an strange case of excessive retain counts for a view controller that I'm loading when a button is pushed.
This is the code:
-(IBAction)new
{
if (!viewSpace)
viewSpace = [[ViewSpace alloc] initWithNibName:#"ViewSpace" bundle:nil];
viewSpace.delegate = self;
viewSpace.view.frame = CGRectMake(0, 0, viewSpace.view.frame.size.width, viewSpace.view.frame.size.height);
[self presentModalViewController:viewSpace animated:YES];
NSLog(#"Count Retain: %d",[viewSpace retainCount]);
}
-(void)viewSpaceWasDissmissed:(id)sender
{
[self dismissModalViewControllerAnimated:YES];
[viewSpace release];
NSLog(#"Count Retain: %d",[viewSpace retainCount]);
}
When the IBAction New is executed first time, the retain count is 5 when just is created. (It must be 1).
When the ViewSpace object must be unload calls viewSpaceWasDismissed function in order to remove the modal view and release the previous object.
The problem is that never the retain count reach 0 and the dealloc method of ViewSpace never is called causing memory leaks.
My question is how is possible that a recently created ViewController have 5 retains? I made sure that is never created before.
Thanks.
Cocoa is probably retaining the view controller 4 times internally for reasons of its own. This isn't a problem.
More generally, the -retainCount method is useless for reasons like this, and you should never call it. It will not help you, and it will confuse you.
To debug your leak, I suggest using the leaks Instrument, inspecting the object, and analyzing where each retain and release is coming from to determine whether any are incorrect.
Check the documentation for -retainCount. I believe it says that you should not be calling it yourself - you just need to take care of any retains that you cause, and don't worry about the 'actual' retain count.
You're doing two things wrong here:
The Current view controller retains the modally presented view controller and releaseds it when it is dismissed. So you should release viewSpace after it is presented, and you don't need the release message in the dismissModalViewController method. As an aside ViewSpace is a poor name for a view controller. I had to read to the line where you are presenting it as a view controller before I knew it was a view controller. I think ViewSpaceController is a more descriptive name.
You are using retainCount which is always a bad idea. All that matters is that in your new method you created an owned object (with the alloc) and you balanced that ownership with a release (or at least you will do when you put in the correction I suggested in point 1) That's it. You took ownership of an object and you released it. The retainCount method tells you absolutely nothing that can be of any use to you. Don't do it. Just balance ownerships with release, and that is all that matters.
I'm not 100% sure of every count but here are some:
Instantiation - 1
NIB - 1+
Strong Properties (1+)
Additionally any properties that list it as a strong property (in ARC).
I noticed that when you launch a nib and you use components of the controller in the nib design, it will increase reference counts (in a strong manner) on the controller instance.
I want to ask a stupid question about the iPhone application. I am the green of the iPhone app. I read the following code in the Apple website.
MyViewController *aViewController = [[MyViewController alloc] initWithNibName:#"MyViewController" bundle:[NSBundle mainBundle]];
[self setMyViewController:aViewController];
[aViewController release];
And I have a question, how it means of the 'release' in the line 3?
Does it presents the memory clear? or the program take control of that object? or other meanings. Thank you very much.
When you alloc something, the object you get will have a retain count of 1 - this means that this object is currently being used by someone, so it should not be removed from memory. If you call retain on an object it will increase the retain count, meaning the object is being used by 2 things. If the retain count reaches 0, it implies that the object is no longer being used by anything and it can be removed from memory. You can decrease an object's retain count by calling release on the object.
In your example, aViewController is alloc'd and after line 1 has a retain count of +1.
It is then set as the view controller in line 2. This method is therefor taking ownership of the object, so should retain it for its own use.
Line 3, we don't want anything more to do with the view controller, so we release our hold of it. The retain count decreases by one - and it is now up to the new owner to release it when it is finished with it.
You might find it helpful to read through the memory management section of this tutrial
Whenever you call alloc, you own a reference to the object that comes back, and you must call release to indicate that you no longer intend to use that reference.
In the above case, you have allocated a new view controller and assigned it to a property of your class. Assuming the property is declared with the retain option, the property will acquire its own reference to the view controller by called retain on it. So there are now two active references to it. The property will eventually release its reference (either when it is assigned a different view controller, or when your class is finalised). But if you don't call release yourself, one reference will remain, and the view controller will never be freed.
In short, you must match every alloc with a release, otherwise things will leak.
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.