small medium large xlarge

Back to: All Forums  Core Data
Gappleatchenal_pragsmall
07 Oct 2009, 15:59
Gordon Apple (29 posts)

One thing that has held me back from using CoreData is that I never understood how to include an NSDictionary (or NSMutableDictionary. My main data hierarchy has objects that have only two ivars: An array of lower-level objects; A dynamic dictionary of parameters (sometimes with references to other complex objects).

I haven’t fully read the book yet, but the last chapter, dealing with Defaults, seems to address that issue, although obliquely. What I would like is a straightforward piece of code that handles the general issue of dictionaries in CoreData. I don’t even need to know how it works – I just want to use it. How about it?

Different subject: The intro in the eBook seems to indicate that it is complete. When do we get contents and index?

Avatarsmall_pragsmall
11 Oct 2009, 17:03
Marcus S. Zarra (284 posts)

The latest ebook update should have the contents and the index. As for the dictionaries question. Core Data does not really have a NSDictionary type concept directly. It expects the attributes of the object to be defined in the data model and not be loosely typed like you have described. To build something that has the same concept as NSDictionary data storage you would need to build something like the Defaults recipe in the book.

Having said that, you will get the most efficiency and greatest elegance in design if you define your data structures clearly in the model as opposed to leaving it open.

Gappleatchenal_pragsmall
17 Oct 2009, 15:55
Gordon Apple (29 posts)

Which is exactly what I do not want to do and why I’m not using CoreData. I have found much advantage in the dictionary approach vs ivars. As I add new features, I can add new keys and entries into the dictionaries and not burden objects that do not include those features. Design wise, it was one of the best decisions I ever made. However, it seems to preclude using CoreData for persistent storage.

Avatarsmall_pragsmall
27 Oct 2009, 00:04
Marcus S. Zarra (284 posts)

What you are describing is counter to proper data model design. So the short answer is no, you cannot store a NSDictionary in Core Data as that defeats the purpose of having proper data structures.

Gappleatchenal_pragsmall
11 Nov 2009, 18:12
Gordon Apple (29 posts)

I’m curious about your use of “proper data model design” and ‘proper data structures”. Is that a formal term? I have done the other way in the past, but now have only one type of “Shape” class with no subclasses. After all, there is only one NSBezierPath class. I find this approach far superior to the usual litany of subclasses taught in almost every book and course in object oriented programming. I also do not let shapes draw themselves. For that, I have a separate shape renderer class which is actually quite simple, even for complex shapes. Hopefully, that will help with cross-platform development.

Avatarsmall_pragsmall
17 Nov 2009, 16:59
Marcus S. Zarra (284 posts)

One object does not a data model make. A simple NSBezierPath can be stored in a transformable attribute on an entity.

A data model is a complex data structure. If you only have NSBezierPath objects with no color, no names, no descriptions, etc. then you definitely do not need Core Data. Although I am at a loss how an application can only have paths as its data.

Lastly, if you are worried about cross platform then I recommend you do not use Core Data. Core Data is not designed to be cross platform and you will be fighting an up hill battle.

You must be logged in to comment