Databases Reference
In-Depth Information
CHAPTER 10
Dynamic Parameters
If you have a document-style application, you will need to work with document-
specific parameters or settings. For example, in a word processor, some
settings are specific to one document, and some settings apply to the entire
application. We have access to a great implementation for storing application-
level parameters: NSUserDefaults . However, there is no reusable storage system
for document-level parameters provided by the APIs. In this chapter, we'll
build that reusable storage system within Core Data.
System-level and user-level preferences are extremely useful and easy to
access on OS X. One call to standardDefaults on NSUserDefaults from anywhere in
the application instantly gives you access to the defaults for the currently
logged in user. However, sometimes we don't want to store preferences at the
user level but would prefer to store them at the file level.
When working with a Core Data application, the natural first solution may
seem to be to create a table for these parameters and access them from
within the Core Data API. The problem with this solution occurs when we are
accessing those parameters. No longer is it a single call to standardDefaults on
NSUserDefaults ; now it looks more like this:
CDPreferences/MyDocument.m
- ( void )clunkyParameterAccess
{
NSManagedObjectContext *moc = [self managedObjectContext];
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:[NSEntityDescription entityForName:@ "parameter"
inManagedObjectContext:moc]];
[request setPredicate:[NSPredicate predicateWithFormat:@ "name == %@" ,
@ "default1" ]];
NSError *error = nil;
NSManagedObject *param = [[moc executeFetchRequest:request
error:&error] lastObject];
 
 
 
Search WWH ::




Custom Search