Re: Core Data, bindings and synchronizing.
Re: Core Data, bindings and synchronizing.
- Subject: Re: Core Data, bindings and synchronizing.
- From: Jim Correia <email@hidden>
- Date: Fri, 16 Feb 2007 09:14:53 -0500
On Feb 16, 2007, at 8:56 AM, Ryan Homer wrote:
Thanks for the responses. It seems like you're saying that I should
try to use one managed object context. I guess I'm accustomed to
trying to keep things private in my classes but with Cocoa, it
seems you have to learn how to break out of that habit a bit.
A managed object context is a scratchpad - a place where you modify
managed objects, and eventually save or discard those modifications.
You only need more than one managed object context in the case where
you want separate scratchpads in which to work. One example of why
you might want to do this is that you want to make a few discrete
changes, and save them, independently of changes in another context.
Once you do that, you are now responsible for communicating changes
between the contexts. If you don't really need two contexts, use one
as Michael suggests. It will be easier.
This does NOT automatically update my view because there are now
two instances of the moc and each is in a different state. I have
tried using a shared moc and this DOES indeed keep the view in
sync with my background data changes, but I was wondering what
solutions others have used in cases like this. One immediate
"situation" that arises is that there is now no simply way to
know when we are no longer using the moc and therefore release it
from memory.
It's not clear why you wouldn't know when you're no longer using
an object...
What I meant here was that the release of objects is usually done
in the dealloc, but my dealloc would now have to be "smart" to know
to release the moc only when it is the last surviving instance...
hmmm, that would probably be [self retainCount] eh? :-)
You should not be making memory management decisions based on the
current retain count. See the memory management documentation for the
policy.
Jim
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden