Question

I created a custom LocationGenerator class that uses CoreLocation and Reverse Geocoding, and generates (when asked) a custom Location object. My custom Location object has two instance variables – Address and GPS…both point to instance of two custom classes – Address is a bunch of strings and GPS is three floats – latitude, longitude and altitude.

Location = Address + GPS

For this to work, I needed to create three custom classes – Location, Address and GPS, all with default values set in their respective init methods.

Then I moved to Core Data. In the model I have these entities – Item, Location, Address and GPS. Item entity has some simple string properties and a Location relationship.
The location entity has a Address and GPS relatioship.

Since I moved to Core data, I deleted the custom classes Location Address and GPS I mention above and let Xcode generate classes from based on core data model.

The problem is, I am not sure how to create a Location instance in LocationGenerator anymore.
My former class definitions for Location and Address and GPS are gone, and in those from core data I should not override the init method.but should those generatede classess be a blueprint for my new Location object?

I guess my question is, how should I generate a location object in the LocationGenerator.
Should the LocationGenerator have its Location object created “inside” the managed object context?
To clarify from the UI point of view -I am just in the process of creating an Item, but it is not created yet, it waits for the Location..and only then is it inserted into core data..
Should I look at all objects that are created in the context the same way as i looked at objects before, with the only difference that they are in the context (and managed by the CD rules) and they persist?

Answer 1

The designated initializer for managed objects (Core Data objects, that is) is -initWithEntity:insertIntoManagedObjectContext: which is to say that you can’t create a managed object without it being associated with a managedObjectContext. You indicate that you want to create the object, and then at some time later, decide whether or not to store it. There are essentially two ways to do that. The first way is to have some other object type that’s not an NSManagedObject, but which you can use to populate an NSManagedObject subclass later when you decide to it should be persisted. The other way is to just created the managed object in the context, and then delete it from the context if it turns out that you don’t need it.

NSManagedObjectContexts can be thought of as “scratch pads.” Nothing is actually persisted until you -save: the context, so if you’re going to be able to make a determination of whether or not to persist the object in the same workflow in which you’re going to save the context, the second way is probably the way to go. If the lifetime of this pre-persisted data is longer than the standard workflow you’re doing with your ManagedObjectContexts then the first way might be better.

HTH.