I'm retrofitting a program to work with core data. This program
displays a number of paragraphs in a scroll view. For reasons having
to do with the functionality of the program, each paragraph is stored
as its own NSString.
In it's current implementation, my model is an NSArray of NSStrings,
one for each paragraph. This works well because the string's
position in the array is representative of its position in the view.
I'm sure you all see where this is going. There are no arrays in Core
Data. To compensate for this, I have assigned each of my "Paragraph"
entities an "index" property which represents it's position in the view.
This works, but doesn't work well. Every time I insert or remove a
Paragraph entity, I have to fetch all the remaining ones and renumber
their indices. This takes a lot of messy code.
I was thinking, at least, I could subclass NSManagedObject and
implement the KOV array accessor methods (countOfX, objectInXyAtY,
insertObject:inXAtIndex, etc.). These methods would take care of all
the messy fetching and re-assigning of indices so that the code was
out of the way.
Is this the "right" way to go about emulating an array in Core Data?
Will NSManagedObject explode if it suddenly finds itself in
possession of removeObjectFromXAtIndex?
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden