I'm just learning core data and mostly coping, but having a little bit of trouble thinking about how I'll implement it.
I want to access the same Core Data from throughout my app. What would be the best way to access it from multiple classes? Would it be recommended to have it as a global variable (normally not recommended in object oriented programming), or to pass it as an instance variable between classes?
Core data model will be available throughout your app. You can easily access the managed object through out your app. You just need to make an instance of the AppDelegate class.
Say for example you have stored contacts. You can just use [managedObject valueForKey:#"name"] in any of the view controllers.
1. Create an instance of the appDelegate
self.theappDel=[[UIApplication sharedApplication] delegate];
2. Get the context,fetch request and entity description.
NSManagedObjectContext*context=[self.theappDel managedObjectContext];
NSEntityDescription*entity=[NSEntityDescription entityForName:#"Contacts" inManagedObjectContext:context];
NSFetchRequest*request=[[NSFetchRequest alloc] init];
[request setEntity:entity];
NSManagedObject*managedObject=nil;
NSError*error=nil;
NSArray*objectList=[context executeFetchRequest:request error:&error];
3. Get the managed object from the array.
if([objectList count]>0)
managedObject=[objectList objectAtIndex:0];
NSLog(#"The name: %#",[managedObject valueForKey:#"name"])
4. Pass the name object using a singleton(or any convenient method) pattern, in other view controllers that you need it.
Pass the NSManagedObjectContext instance, or if you just need to handle one object the NSManagedObject instance, to the next class.
Like it's done in Xcodes Core Data templates.
Take a look at the MagicalRecord Library. Not only does it make a lot of common fetch requests much more succinct, it also makes it easier to access your managed object context just by using [NSManagedObjectContext defaultContext];
Related
I have found these Stanford tutorials https://itunes.apple.com/us/course/ipad-iphone-app-development/id495052415, and have been listening a lecture about core data, which is really great.
It shows how to access Core Data via UIManagedDocument... Only thing I don't understand how UIManagedDocument knows which model should it use, because I don't see it set anywhere?
To sum it when using UIManagedDocument, how do you define database model that is gonna be used?
I found the answer:
'UIManagedDocument' takes all the models from your application's main bundle, and makes union of these models. If you only have one model that model is used.
This can be changed by overriding 'UIManagedDocument' class.
Loading a Data Model
In some cases, you do not have to write any code to load a model. If you use a document-based application on OS X, NSPersistentDocument manages the task of finding and loading your application’s model for you. If you use Xcode to create a non-document application that uses Core Data (for OS X or for iOS), the application delegate includes code to retrieve the model. The name of a model—as represented by the filename used to store it on disk—is not relevant at runtime. Once the model is loaded by Core Data, the filename is meaningless and has no use, so you can name the model file whatever you like.
If you want to load a model yourself, there are two mechanisms you can use:
You can load a single model from a specific URL, using the instance method initWithContentsOfURL:.
This is the generally-preferred technique. Typically an application has a single model, and using this method you ensure that you load only that model. You can also load individual models via URLs and then unify them using modelByMergingModels: before instantiating a coordinator with them.
In cases where you have more than one model—and particularly in cases where the models represent different versions of the same schema—knowing which model to load is essential (merging together models with the same entities at runtime into a single collection would cause naming collisions and errors). This method is also useful if you want to store the model outside of the bundle for your application, and so need to reference it via a file-system URL.
You can create a merged model from a specific collection of bundles, using the class method mergedModelFromBundles:.
This method may be useful in cases where segregation of models is not important—for example, you may know your application and a framework it links to both have models you need or want to load. The class method allows you to easily load all of the models at once without having to consider what the names are, or put in specialized initialization code to ensure all of your models are found.
Accessing and Using a Managed Object Model at Runtime
NSManagedObjectModel *model = <#Get a model#>;
NSFetchRequest *requestTemplate = [[NSFetchRequest alloc] init];
NSEntityDescription *publicationEntity =
[[model entitiesByName] objectForKey:#"Publication"];
[requestTemplate setEntity:publicationEntity];
NSPredicate *predicateTemplate = [NSPredicate predicateWithFormat:
#"(mainAuthor.firstName like[cd] $FIRST_NAME) AND \
(mainAuthor.lastName like[cd] $LAST_NAME) AND \
(publicationDate > $DATE)"];
[requestTemplate setPredicate:predicateTemplate];
[model setFetchRequestTemplate:requestTemplate
forName:#"PublicationsForAuthorSinceDate"];
Using a fetch request template
NSManagedObjectModel *model = <#Get a model#>;
NSError *error = nil;
NSDictionary *substitutionDictionary = [NSDictionary dictionaryWithObjectsAndKeys:
#"Fiona", #"FIRST_NAME", #"Verde", #"LAST_NAME",
[NSDate dateWithTimeIntervalSinceNow:-31356000], #"DATE", nil];
NSFetchRequest *fetchRequest =
[model fetchRequestFromTemplateWithName:#"PublicationsForAuthorSinceDate"
substitutionVariables:substitutionDictionary];
NSArray *results =
[aManagedObjectContext executeFetchRequest:fetchRequest error:&error];
Totally new to Objective-C and Core Data, coming from a .net background I really want to put all of my fetch requests into some sort of class that I can call, preferably statically to get my objects, something like:
ObjectType *myObject = [CoreDataDAL GetObject:ID];
Anyone have a pattern to implement this?
I am hacking my way through one right now but it's probably not quite right, will post code when I have it.
EIDT:
Here is my code as it stands right now - seems to work great - please rip it part if I am going down the wrong road - here is the basic DAL:
#import "CoreDataDAL.h"
#import "CoreDataAppDelegate.h"
#implementation CoreDataDAL
#synthesize managedObjectContext;
-(id)init {
if (self=[super init]) {
CoreDataAppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];
self.managedObjectContext = appDelegate.managedObjectContext;
}
return self;
}
-(Client *) GetClient:(NSString *) ClientID{
/* Client Fetch Request */
NSFetchRequest *request = [[NSFetchRequest alloc]init];
NSEntityDescription *entityType = [NSEntityDescription entityForName:#"Client" inManagedObjectContext:managedObjectContext];
[request setEntity:entityType];
NSPredicate *predicate =[NSPredicate predicateWithFormat:#"ClientID==%#",ClientID];
[request setPredicate:predicate];
NSError *error;
NSArray *entities = [[managedObjectContext executeFetchRequest:request error:&error] mutableCopy];
return [entities objectAtIndex:0];
}
#end
And here is how it is used in my view controllers:
CoreDataDAL *dal = [[CoreDataDAL alloc]init];
Client *client = [dal GetClient:clientID];
[dal release];
Seems straight forward enough, thoughts?
Don't do this; what you're doing is porting a pattern from one context to another where it doesn't really make sense.
For one thing, you shouldn't be modeling IDs at all in Core Data; the framework does that for you with NSManagedObjectID already. Thus a -clientWithID: method on a CoreDataDAL class is redundant. (Note that I've also changed the name of your hypothetical method to follow proper Cocoa naming conventions.) Instead, you can just use -[NSManagedObjectContext objectWithID:] or -[NSManagedObjectContext existingObjectWithID:error:] to get an object based on its NSManagedObjectID.
Similarly, relationship management is handled for you. You don't need to have a method in your DAL that can (say) fetch all of the Address instances that apply for a given Client by evaluating some query. You can just traverse your Client's to-many addresses relationship to get at them, and manipulate the same relationship directly (rather than setting foreign keys etc.).
Finally, if you really do want to have methods to perform specialized queries, you can either specify the query via a fetched property on the appropriate entity for its results, or you can add that method directly to the appropriate class. Class methods in Objective-C aren't like static methods in C++, Java or C# - they can be overridden just as instance methods can, and are much more appropriate for this kind of use.
For example, say your Client entity has a syncID property representing the ID of the object that it represents in some web service. (Note that this is specifically for relating a local object to a remote object, not the "primary key" of the local object.) You'd probably have class methods on the MyClient class associated with your Client entity like this:
#implementation MyClient
+ (NSString *)entityClassName
{
return #"Client";
}
+ (NSEntityDescription *)entityInManagedObjectContext:(NSManagedObjectContext *)context
{
return [NSEntityDescription entityForName:[self entityClassName] inManagedObjectContext:context];
}
+ (MyClient *)clientWithSyncID:(NSString *)syncID
inManagedObjectContext:(NSManagedObjectContext *)context
error:(NSError **)error
{
MyClient *result = nil;
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:[self entityInManagedObjectContext:context]];
[request setPredicate:[NSPredicate predicateWithFormat:#"syncID == %#", syncID]];
[request setFetchLimit:1];
NSArray *results = [context executeFetchRequest:request error:error];
if ([results count] > 0) {
result = [results objectAtIndex:0];
} else {
if (error != NULL) {
*error = [NSError errorWithDomain:MyAppErrorDomain
code:MyAppNoClientFoundError
userInfo:nil];
}
}
return result;
}
#end
This is similar to what you wrote in your DAL class, but instead of consolidating all of the fetches in one place, it puts the logic for fetches appropriate to a particular managed object class on that class, which is really where it belongs. Thanks to the fact Objective-C has true class methods, you can actually put methods like +entityInManagedObjectContext: and +entityClassName on a common base class and then override only the latter as appropriate in subclasses (or even have it generate an appropriate entity name from the class name).
To sum up:
Don't recreate what Core Data already implements for you in terms of things like object IDs, relationship management, and so on.
Leverage polymorphism at both the instance and the class level to keep your code clean, rather than use "utility" classes like "data access layers."
Fetch request properly belong to the individual controllers in the Model-View-Controller pattern. A fetch returns the specific information, in the specific order, required by each individual view. Each fetch is customized for the needs of each particular view. As such, putting all of an app's fetches in a single object would break encapsulation instead of enhancing it. Only fetched properties and fetched relationships belong in the data model itself.
The managed object context performs the function of the data object in simple apps. It implements all the functions necessary to get information in and out of the Core Data stack e.g. - objectWithID:. Much of the time, all you need to do is pass the context to controllers and let them configure fetches to it.
If your app is large or has multiple context, you can always wrap up the context/s in a custom manager class with various accessors and convenience methods to make the Core Data operations run more smoothly. You can legitimately and safely implement the manager class as a singleton to make accessing it everywhere in the app easy.
Edit:
The code looks okay except for the mutable copy. It's pointless and will leak memory. The entities array is only needed for one line and it's autorelease. The Client objects retention is managed by the context. You should test the error and at least log it for debugging.
You do want to avoid "get" and "set" for method names that are not accessors. The runtime looks methods that begin with "get" and "set" to find accessors. By convention, all method names start with lower case. You might want to make the method name more descriptive so that it auto-comments when you read it months down the road.
So:
[theCoreDataDal GetClient:vaugelyNamedString];
to
[theCoreDataDal clientWithClientID:vaugelyNamedString];
The problem your going to run into with trying to cram everything into one object is that the fetches are usually unique and configured for the needs of a specific interface.
Moreover, you usually start with a fetch to find specific objects but then you spend the rest of the time walking relationships based on input unknown until runtime.
Core Data is the data access layer. Most of the code you write for Core Data is actually controller code. There is nothing conceptually problematic about this GetClient method but how often are you going to execute this particular fetch?
When I create a Data Model Manager object, I use it largely to store boiler plate code. For example, while each fetch request is unique, they all start out the same with an entity description so I autogenerate methods to return the basic fetch for each entity and put that in the manager. Then I have another boiler plate method to actually perform the fetch. In use, a controller ask the manager for a fetch object for a specific entity. The controller customizes the fetch and then sends it back to the manager to perform the fetch and return the results.
Everything boiler plate is in the manager and everything customized is in the controller.
From an Apple example, I have this:
Event *event = (Event*)[NSEntityDescription
insertNewObjectForEntityForName:#"Event"
inManagedObjectContext:self.managedObjectContext];
Event inherits from NSManagedObject. Is there a way to avoid this weird call to NSEntityDescription and instead just alloc+init somehow directly the Event class? Would I have to write my own initializer that just does that stuff above? Or is NSManagedObject already intelligent enough to do that?
NSManagedObject provides a method called initWithEntity:insertIntoManagedObjectContext:. You can use this to do a more traditional alloc/init pair. Keep in mind that the object this returns is not autoreleased.
I've run into the exact same problem. It turns out you can completely create an entity and not add it to the store at first, then make some checks on it and if everything is good insert it into the store. I use it during an XML parsing session where I only want to insert entities once they have been properly and entirely parsed.
First you need to create the entity:
// This line creates the proper description using the managed context and entity name.
// Note that it uses the managed object context
NSEntityDescription *ent = [NSEntityDescription entityForName:#"Location" inManagedObjectContext:[self managedContext]];
// This line initialized the entity but does not insert it into the managed object context.
currentEntity = [[Location alloc] initWithEntity:ent insertIntoManagedObjectContext:nil];
Then once you are happy with the processing you can simply insert your entity into the store:
[self managedContext] insertObject:currentEntity
Note that in those examples the currentEntity object has been defined in a header file as follows:
id currentEntity
To get it to work properly, there is a LOT of stuff to do. -insertNewObject:... is by far the easiest way, weird or not. The documentation says:
A managed object differs from other
objects in three main ways—a managed
object ... Exists in an environment
defined by its managed object context
... there is therefore a lot of work
to do to create a new managed object
and properly integrate it into the
Core Data infrastructure ... you are
discouraged from overriding
initWithEntity:insertIntoManagedObjectContext:
That said, you can still do it (read further down the page to which I linked) but your goal appears to be "easier" or "less weird". I'd say the method you feel is weird is actually the simplest, most normal way.
I found a definitive answer from More iPhone 3 Development by Dave Mark and Jeff LeMarche.
If it really bothers you that you use a method on NSEntityDescrpiton rather than on NSManagedObjectContext to insert a new object into an NSManagedObjectContext, you can use a category to add an instance method to NSManagedObjectContext.
Create two new text files called NSManagedObject-Insert.h and NSManagedObject-Insert.m.
In NSManagedObject-Insert.h, place the following code:
import <Cocoa/Cocoa.h>
#interface NSManagedObjectContext (insert)
- (NSManagedObject *)insertNewEntityWithName:(NSString *)name;
#end
In NSManagedObject-Insert.m, place this code:
#import "NSManagedObjectContext-insert.h"
#implementation NSManagedObjectContext (insert)
- (NSManagedObject *)insertNewEntityWithName:(NSString *)name
{
return [NSEntityDescription insertNewObjectForEntityForName:name inManagedObjectContext:self];
}
#end
You can import NSManagedObject-Insert.h anywhere you wish to use this new method. Then replace the insert calls against NSEntityDescription, like this one:
NSManagedObject *newManagedObject = [NSEntityDescription insertNewObjectForEntityForName:[entity name] inManagedObjectContext:context];
with the shorter and more intuitive one:
[context insertNewEntityWithName:[entity name]];
Aren't categories grand?
This is for an iPhone App, but I don't think that really matters. I need to send a custom object (which is managed by Core Data) over bluetooth using the iPhone's GameKit. Normally, I would just use an NSKeyedArchiver to package up the object as a data object and ship it over the line, then unarchive the object and I'm done. Of course, I would need to implement the initWithCoder: and encodeWithCoder: methods in my custom object as well.
I'm not sure if this can be done with an NSManagedObject class, which is managed by Core Data or not. Will they play nice together? I'm guessing once I ship the encoded managed object over to the other device and unencode it, I would just add this received object to the other device's context. Is this correct? Am I missing any steps?
An NSManagedObject instance can't meaningfully exist outside of an NSManagedObjectContext instance, so I wouldn't bother trying to do the NSCoding dances required to directly serialize and deserialize an NSManagedObject between two contexts (you can do this; see below). Instead I would create a dictionary with the appropriate attribute key/values (you can get the attribute names via the managed object instance's attribute names via instance.entity.attributesByName.allKeys (you can use [instance dictionaryWithValuesForKeys:keys] to get the dictionary of attribute:value pairs) . I would send relationship information as NSURL-encoded NSManagedObjectIDs. Don't forget to include the instance managedObjectID (as an NSURL) in the dictionary so that you can reconnect any relationships to the object on the other end. You'll have to recursively create these dictionaries for any targets of relationships for the instance you're encoding.
Then send the dict(s) across the wire and reconstitute them on the other end as instances in a new managed object context (you can use setValuesForKeysWithDictionary:).
You may notice that this is exactly what the NSCoder system would do for you, except you would have to use the classForCoder, replacementObjectForCoder: and awakeAfterUsingCoder: along with a custom NSDictionary subclass to handle all the NSManageObject-to-NSDictionary mapping and visa versa. This code is more trouble than it's worth, in my experience, unless you have a complex/deep object graph that you're trying to serialize. For a single NSManagedObject instance with no relationships, it's definitely easier to just do the conversion to a dict and back yourself.
This sounds like a job for TPAutoArchiver.
I suggest the dictionary solution for simpler options. However, here is how I solved the issue. My model was already sizable and robust, with custom classes and a single root class above NSManagedObject.
All that I needed was for that single class to call the appropriate designated initializer of NSManagedObject: [super initWithEntity:insertIntoManagedObjectContext:]. This method, and the metadata in an NSEntityDescription is what sets up the implementations of all the dynamic accessors.
- (id)initWithCoder:(NSCoder *)aDecoder {
CoreDataStack *cds = [LibraryDiscoverer unarchivingCoreDataStack];
NSEntityDescription *entity = [cds entityDescriptionForName:[[self class] entityName]];
NSManagedObjectContext *moc = [cds managedObjectContext];
self = [super initWithEntity:entity insertIntoManagedObjectContext:moc];
self.lastEditDate = [aDecoder decodeObjectForKey:#"lastEditDate"];
return self;
}
The CoreDataStack is my abstraction around CoreData. The LibraryDiscoverer is a global access hook to get hold of the core data information. The entityName is a method defined to provide the entity name from the class name; if you follow a naming convention (i.e. class name = entity name) it can be implemented generically.
All the other initWithCoder: methods in my class hierarchy are standard NSCoder, with the note that you don't need to encode both directions of a relationship, CoreData reconnects that for you. (As it always does, including with the dictionary solution.)
Is there a way to initialize a managed object outside of a context. I'm basically trying to alloc/init a Managed Object outside of a context first, then figure out if I really want to insert the object, and then inject it into the datastore using an existing managed object context.
Is this possible, or does it go against the intended usage of Core Data?
Managed Object are "managed" by the context, therefore you cant really instanciate them with alloc since they are not meant to be.However, instantiating a managed object through the context does not persist it until you call save method on the context, so you would have the same effect using the context to instanciate it and only saving after you figure out that you really want to use the object.
No, you cannot instantiate an NSManagedObject instsance outside of an NSManagedObjectContext (well, you can, but bad things will happen and your program will almost certainly not work as you'd hoped). You can, however, create an NSInMemoryPersistentStore-backed NSManagedObjectContext. It's slightly more setup (not much) and everything vanishes when you dealloc the in-memory store. In the mean time, you get all the benefits of Core Data's object graph management.
For anyone who stumbles upon this question, here's how I accomplished what the OP was probably going for:
NSManagedObjectContext *moc = AppDelegate.managedObjectContext;
NSEntityDescription *entity = [NSEntityDescription entityForName:#"MyModel"
inManagedObjectContext:moc];
MyModel *model = [[MyModel alloc] initWithEntity:entity
insertIntoManagedObjectContext:nil];
What you are probably shooting for is multiple contexts. You can create an additional "scratchpad" context and then merge any changes back into the main context. One of Apple's iPhone sample projects accomplishes this exact thing. You'll have to log into the dev center to find it.