Re: [Solved - duh!] Core data storage of objects whose class is loaded from a bundle
Re: [Solved - duh!] Core data storage of objects whose class is loaded from a bundle
- Subject: Re: [Solved - duh!] Core data storage of objects whose class is loaded from a bundle
- From: Rick Hoge <email@hidden>
- Date: Thu, 29 Jan 2009 16:32:43 -0500
Not surprisingly, the problem had nothing to do with loading the
classes via plugins.
In my plugin subclasses I was calling -initWithCoder: as follows:
-(id)initWithCoder:(NSCoder*)decoder {
self = [super initWithCoder:decoder]; // Returns instance of parent
class
return self;
}
which was returning an instance of the parent class and not the
subclass. After I changed this to the version below, everything
worked fine - Core Data encodes and decodes the correct object class -
loading the class from a plugin is no problem.
-(id)initWithCoder:(NSCoder*)decoder {
self = [[MyPluginSubclass alloc] init]; // I know there will be no
subclasses
[super initWithCoder:decoder];
return self;
}
On 29-Jan-09, at 3:28 PM, Rick Hoge wrote:
I am working on an app in which plugin subclasses are loaded from
bundles at launch time (didFinishLaunching in app delegate). The
base plugin class is specified in a framework against which the main
app is linked.
I can create instances of these dynamically loaded subclasses, and
assign them as 'transformable' attributes belonging to Core Data
entities. During a session the object behaves as expected, and I am
able to save the core data store to disk (the plugin base class and
dynamicaly loaded subclasses conform to the NSCoding protocol).
However when I reload the core data store (i.e. quit the app and
open the persistent document again), it seems that Core Data is
unarchiving the coded objects as instances of the base plugin class
and not the subclass that was (and is again) dynamically loaded. I
was hoping that the correct subclass would have been used since the
plugins have already been loaded by the app *before* I unarchive the
document.
I realize that this approach may be 'playing with fire' since weird
things will surely happen if some plugins aren't available when the
store is re-opened in the future (although this can be handled
gracefully I think). I also realize I can just make such attributes
'transient' and manage creation and reloading of the store myself.
However it's certainly nice when Core Data does all this stuff for
you... I'd hate to introduce complexity just because I was missing
something obvious about how to load these attributes.
So I was wondering: does anyone know a way to force the correct
class to be used when reloading such an attribute?
Thanks in advance,
Rick
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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
(43092.6825)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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