0

I'm currently diving further into Core Data and have some minor confusion about using Core Data NSManagedObject Models.

For example, I would have a "Contact" Entity that has properties such as firstname, lastname, address, etc...

What I'm trying to understand is if there's any "best practice" for using NSManagedObject as regular NSObjects, if that is at all possible.

For example, I have a server returning some contacts data in JSON, But I want to return it as some sort of a NSObject so it would have its own properties, methods, etc ... But on the other hand it would be stupid to create 2 classes to represent the Contact Entity - One for handling situations where I want to provide a sanitised object from server data (NSObject), and another when I want to handle Core Data (NSManagedObject). Is there any way to use a single object for both purposes ? What would be the best practice in this situation ?

Edit: Here's the general problem I'm having : http://pastebin.com/WHWNqj2f

Shai Mishali
  • 9,224
  • 4
  • 56
  • 83
  • the best practice is to have a single object for both cases. just implement a custom init method ([[YourObject alloc] initWithJSONDictionary: ..]) in your NSManagedObhect and assign the corresponding values – CarlJ Oct 14 '13 at 13:43
  • @CarlJ - The problem with that is that I can't just initialize a NSManagedObject without giving it a context. Also, I couldn't create an NSObject that could be used with Core Data. That's exactly the problem I'm having. – Shai Mishali Oct 14 '13 at 13:44
  • than create a NSManageObject pass the values to it and dont save the context. – CarlJ Oct 14 '13 at 13:47
  • Have to be able to save the context randomly without limitations ... That's part of the issue. Meaning for example, I have an array for newly created "Contact" objects and I'm comparing them vs. the ones I currently have in my SQLite. Somewhere along that road I'd probably have to save the context with some of the new updates, but I wouldn't want the objects in the NSArray to be included in that. A bit hard to explain, hope you got my point. – Shai Mishali Oct 14 '13 at 13:49
  • sry, i dont understand the specific problem, but i would always recommend to use NSManagedObject. – CarlJ Oct 14 '13 at 13:53
  • Hey @CarlJ, thanks for reading this. Maybe this short example/paste would be easier to understand: http://pastebin.com/WHWNqj2f – Shai Mishali Oct 14 '13 at 13:58
  • There are Frameworks available such as RestKit, that will provide you with JSON mapping objects and Core Data objects to handle this exact issue. – Tim Oct 14 '13 at 14:04
  • I'm trying to use MagicalRecord to ease up the work, Wouldn't RestKit replace it? MagicalRecord seems great fore CoreData but it doesn't really work for the other kind of situation. – Shai Mishali Oct 14 '13 at 14:05
  • Plus I don't want an entire HTTP system, I already have AFNetworking set up and I love it. If there's something that'll give me just JSON mapping that'll be wonderful. – Shai Mishali Oct 14 '13 at 14:06
  • @ShaiMishali and why you dont create two separated context for your Server and Local contacts and never save the "server context" – CarlJ Oct 14 '13 at 14:17
  • @CarlJ thats actually a great idea I think ! Thanks ! – Shai Mishali Oct 14 '13 at 14:22
  • I'm wondering though if thats the best practice – Shai Mishali Oct 14 '13 at 14:23
  • A JSON can be converted in a NSDictionary easily without any frameworks, than you can compare each key in dictionary with the correspondent property in NSManagedObject. – Leonardo Oct 14 '13 at 16:22
  • Its not a problem converting to a NSDictionary but thats not what I want nor its what I asked. For now I'm using a separate context and that seems to do the trick even though I'm still having some minor issues. THx. – Shai Mishali Oct 14 '13 at 16:54

1 Answers1

0

There's no need to have more than one class for this-- just use the managed object in all cases. You mention in comments that "I can't just initialize a NSManagedObject without giving it a context" but in fact that's not true. When you create a managed object using either [NSManagedObject initWithEntity:insertIntoManagedObjectContext:] or [NSEntityDescription insertNewObjectForEntityForName:inManagedObjectContext:] you do not have to provide a managed object context. It's OK if that argument is nil, as long as you provide a valid NSEntityDescription. What you get is a managed object that's not tied to any managed object context. This can be handy for temporary objects, because you can save changes in any managed object contexts you have without saving this object.

If you want to save the object to a managed object context later on, use [NSManagedObjectContext insertObject:]. At that point the managed object becomes associated with the context, so saving changes to the context will save the object.

Tom Harrington
  • 69,312
  • 10
  • 146
  • 170
  • Hey Tom, Thanks - I used to work with that approach but that prevents me from using MagicalRecord ... So unfortunately I'm trying to fix it up a bit. Was the suggestion of using 2 separate contexts viable ? – Shai Mishali Oct 14 '13 at 20:29