views:

164

answers:

3

Okay, PLEASE bear with my description of my situation:

I have a Core Data model that (in a simplified description) includes a GridManager object. The GridManager holds a set of Grid objects (via a to-many relationship). The Grid object contains a set of Cell objects (via a to-many relationship).

In my app, I have a GridView that contains a series of sub-views (of type CellView). The GridView has a representedGrid property and the CellView has a representedCell property (both nonatomic, retain). In the setRepresentedGrid method of GridView, I set the representedCell property of each CellView (subviews of the GridView) to one of the cells in the representedGrid.

NOW, I have two questions:

First, since the cells and the grid are Managed objects, do I still need to release the representedGrid and representedCell properties of the GridView and CellView classes when they dealoc? I figure I do (just as with any retained property), but at one point I thought this was causing a problem with my app--hmmm... just thought, since I write my own setters, and I don't actually retain the grid/cell, perhaps I DON'T need to release them?

Second, only one grid from the gridManager is active at a time. When I switch the gridView.representedGrid from one grid to another, how do I "release" the first grid (and it's associated cells) so that it isn't needlessly taking up memory (given that we're talking about managed objects).

Thanks SO much!

A: 

Yes, you need to release your representedGrid and representedCell properties in your dealloc method. If you didn't, the retain/release methods would not be balanced- your setter would be retaining the object, and with no corresponding release, the object will never be deallocated.

When written properly, a retain setter will release its old value and retain the new value. So there is no need to release the old grid when setting gridView.representedGrid.

Why are you writing your own setters, out of curiosity?

sbooth
I'm writing my own setter so that by pointing a GridView to its grid, it automatically sets up its CellView sub-views to represent the cells in the grid. It also adds itself as an observer to notifications from the grid (so the view can change when the grid changes).In general programming concepts, one of reason for properties (rather than direct access to fields) is to provide customized getters/setters that can perform necessary functions when an associated property is accessed. Of course, I synthesize the vast majority of my properties.
FTLPhysicsGuy
A: 

As I understand it you should and can avoid custom getters and setters and then you can leave core data to do it's thing and not worry about retain/release.

As for reducing memory overhead you can ask core data to turn your object to fault using this method: refreshObject:mergeChanges:

Check out the Apple documentation here: http://gemma.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreData/index.html. It's all there and hopefully I've been able to give you the right terms to look for.

Hope that's some help.

Tom Duckering
Your comment about refreshObject refreshed my memory -- I now recall reading about that when I first looked into Core Data. Thanks!
FTLPhysicsGuy
A: 

If your setters are retaining the managed objects then you need to release them to match the retain/release. However you may not need to retain the managed objects depending on how the application is designed.

Without seeing all of the code it is difficult to give solid advice but you can use the analyzer to check for leaks, use instruments to make sure your memory is not increasing out of control, etc. And last but not least you can turn off retains, switch them to assigns and see if it crashes. Since the NSManagedObjectContext will retain the objects there is a fair chance that your views do not need to retain the NSManagedObject instances at all.

Marcus S. Zarra