Is there a way to define which attributes of an entity should define its objects' NSManagedObjectID?
Rather than having to build extra dictionaries and loops to compare them by property values, I'd like to be able to just use -[NSManagedObjects isEqual:] directly, and the NSSet functionality that would also allow.
Put another way: if an entity has an attribute that would logically be its primary key, how to tell CoreData to use it as such for object equality tests?
You don't. And subclassing wouldn't help anyway.
Core Data doesn't care if you create duplicate records. As far as it's concerned, two managed objects are equal if they represent the same underlying instance in the persistent store. It has no other concept of "equal" between managed objects.
Subclassing doesn't help because, as the docs for NSManagedObject explain:
NSManagedObject itself customizes many features of NSObject so that managed objects can be properly integrated into the Core Data infrastructure. Core Data relies on NSManagedObject’s implementation of the following methods, which you therefore absolutely must not override: [...] isEqual:,
You can create your own methods for comparing managed objects any way you like, but any behavior that relies on isEqual: is going to get Core Data's standard behavior.
When I have worked with Java applications involving a database and ORM (object relationship manager) the architecture was usually separated so when working with database entities in the database layer you worked directly with the entities. But if you needed to access the entities in the GUI you would create a data transfer object (DTO) of the entity and then use it in the GUI layer.
What is the preferred approach in iOS applications?
One example would be that I do a fetch from Core Data to retrieve some objects in a ViewController and then display the results in a TableView in the ViewController. Is it necessary to convert the NSManagedObjects to DTOs before showing the results?
What is the preferred approach in iOS applications?
Is it necessary to convert the NSManagedObjects to DTOs before showing the results?
No, it is not neccessary. The managed object is already a (generic) object wrapping the database entity. You can access the managed object's properties (ie the entitys attributes) using -valueForKey: calls.
But the preferred approach is to subclass NSManagedObject to fit your entities. In Xcode there is an option to generate subclasses automatically (editor-> generate NSManagedObject subclass). That way you get your own subclass object for your entities and can access their properties using dot notation.
On fetching objects, just let the result be of type of that subclass.
If you want to add custom methods to your entity objects, you should create a category on your managed object subclass. This is because if you change your db scheme and have to let xcode recreate your subclasses, it completely overwrites the and your custom methods would be lost.
I created my own class that I want Core Data to use instead of NSManagedObject:
#interface MyManagedObject: NSManagedObject {
id delegate;
}
I can't use a category since this declares an ivar. All of my Core Data objects use concrete classes rather than being instances of NSManagedObject. I use the code generator to generate these files. Here's an example of what a Contact object might look like:
#interface Contact: NSManagedObject {
}
I know that I can manually change NSManagedObject to MyManagedObject in this generated code, but I will need to do this every time I regenerate the code. Is there any way to make it automatically use my own class?
Additionally, the #import in any solution might be a problem. Ideally I want it to use #class MyManagedObject rather than #import "MyManagedObject.h", since MyManagedObject.h is located in a library and the header needs a folder prefix to be accessible (e.g. #import "MyLib/MyManagedObject.h").
I tried creating a dummy object in the .xcdatamodel file with the same name and specifying that all objects inherit from it, but there are two problems. The first is that it is using #import "MyManagedObject.h", which it can't find due to the reason I specified above. The second problem is that I'm not sure it's a good idea to fool Core Data into thinking the class is inheriting from another Core Data object... even if I'm not generating the code file. I'm guessing that Core Data might be doing some unnecessary things behind the scenes because it believes there is an extra class which my classes are inheriting from.
I guess I can solve the first problem using another layer of classes. For example, I would specify that the objects inherit from MyProjectManagedObject and create a MyProjectManagedObject.h file in my project:
#import "MyLib/MyManagedObject.h"
#interface MyProjectManagedObject: MyManagedObject {
}
... and now my auto generated files will look like this:
#import "MyProjectManagedObject.h"
#interface Contact: MyProjectManagedObject {
}
... which will work. The only problem is the second one I mentioned above about extra code running behind the scenes in Core Data. Is this something to worry about or should I ignore it? Are there any other ways to do this which solve both problems mentioned above?
Don't use inheritance in your data model if you're using the SQL backend. Because of the implementation of the SQL backend, it has horrible performance and space characteristics. (This is Apple's recommendation.)
I may be wrong (I'll double-check), but I think you can do what you want using just the class and header files, without messing with the data model. (This is assuming you don't want to actually store your ivar in the data backend.) Just implement MyManagedObject like you did, and make your subclasses inherent from MyManagedObject instead of NSManagedObject (e.g. Contact : MyManagedObject). Note that you only have to do this in the header files, and not the actual data model. The compiler should figure out the rest.
Take a look at MOGenerator. It'll help with the regenerating the managed object class files at least: it makes you two files for each one. one that you edit and one that is automatically generated. When you regenerate the latter, the former is untouched.
http://digitalflapjack.com/blog/2010/mar/26/mogeneratorftw/
I've recently started down the road of programming in Objective-C, and I'm now looking into Core Data. However, I am confused about exactly what defines the model itself in Core Data.
Here's what I mean: Say I create an entity with some set of attributes using the graphical model builder. I then have Xcode generate code for the corresponding class. Next, I want to create a property in the class that will be used only during run-time and does not need to be stored or retrieved by Core Data. So, I add a variable and a corresponding property to the class (synthesizing it in the implementation)
The new property is not defined in the model builder, but it is defined in the class derived from NSManagedObject. How is it treated in Core Data? Do the properties listed in the class define attributes in the "model" or do only the attributes defined in the model builder define the model?
Similarly, I wanted to add a enum-based property to the class file that, when get or set, accesses or changes an NSNumber attribute in the model. Can I do that without Core Data treating the property as an attribute to be stored and retrieved?
THANKS!
You can add custom properties (and variables) to the code generated for your NSManagedObjects, as you would any other class. These won't become part of the model, but instead will be temporary in memory. It's worth noting that if the managed object were to be dealloc'ed the value in memory would too.
A tip I would suggest if you are just implementing custom accessors to the underlying data is to create a category on the managed object in question. In the accessors, you access the underlying NSNumber and convert it into your enum, defined in the header for the category.
If you need to regenerate the code for the managed object, because say the model changes, you can just delete the class generated for the managed object and regenerate it without needing to merge with any custom code you've added. The category you've added will work all the same as long as the underlying storage property has stayed the same.
You can find out more about categories in the Objective-C Programming Language guide at the ADC.
Can some one explain to me the difference between categories and inheritance in Objective C? I've read the entry in Wikipedia and the discussion on categories there doesn't look any different to that of inheritance. I also looked at the discussion on the topic in the book "Open iPhone Development" and I still don't get it.
Sometimes, inheritance just seems like more trouble than it is worth. It is correctly used when you want to add something to an existing class that is a change in the behaviour of that class.
With a Category, you just want the existing object to do a little more. As already given, if you just want to have a string class that handles compression, you don't need to subclass the string class, you just create a category that handles the compression. That way, you don't need to change the type of the string classes that you already use.
The clue is in the restriction that categories only add methods, you can't add variables to a class using categories. If the class needs more properties, then it has to be subclassed.(edit: you can use associative storage, I believe).
Categories are a nice way to add functionality while at the same time conforming to an object oriented principle to prefer composition over inheritance.
Edit January 2012
Things have changed now. With the current LLVM compiler, and the modern, 64-bit runtime, you can add iVars and properties to class extensions (not categories). This lets you keep private iVars out of the public interface. But, if you declare properties for the iVars, they can still be accessed / changed via KVC, because there is still no such thing as a private method in Objective-C.
Categories allow you to add methods to existing classes. So rather than subclass NSData to add your funky new encryption methods, you can add them directly to the NSData class. Every NSData object in your app now has access to those methods.
To see how useful this can be, look at: CocoaDev
One of favorite illustrations of Objective-c categories in action is NSString. NSString is defined in the Foundation framework, which has no notion of views or windows. However, if you use an NSString in a Cocoa application you'll notice it responds to messages like – drawInRect:withAttributes:.
AppKit defines a category for NSString that provides additional drawing methods. The category allows new methods to be added to an existing class, so we're still just dealing with NSStrings. If AppKit instead implemented drawing by subclassing we'd have to deal with 'AppKitStrings' or 'NSSDrawableStrings' or something like that.
Categories let you add application or domain specific methods to existing classes. It can be quite powerful and convenient.
If you as a programmer are given a complete set of source code for a code library or application, you can go nuts and change whatever you need to achieve your programming goal with that code.
Unfortunately, this is not always the case or even desirable. A lot of times you are given a binary library/object kit and a set of headers to make do with.
Then a new functionality is needed for a class so you could do a couple of things:
create a new class whole instead of a stock class -- replicating all its functions and members then rewrite all the code to use the new class.
create a new wrapper class that contains the stock class as a member (compositing) and rewrite the codebase to utilize the new class.
binary patches of the library to change the code (good luck)
force the compiler to see your new class as the old one and hope it does not depend on a certain size or place in memory and specific entry points.
subclass specialization -- create subclasses to add functionality and modify driver code to use the subclass instead -- theoretically there should be few problems and if you need to add data members it is necessary, but the memory footprint will be different. You have the advantage of having both the new code and the old code available in the subclass and choosing which to use, the base class method or the overridden method.
modify the necessary objc class with a category definition containing methods to do what you want and/or override the old methods in the stock classes.
This can also fix errors in the library or customize methods for new hardware devices or whatever. It is not a panacea, but it allows for class method adding without recompiling the class/library that is unchanged. The original class is the same in code, memory size, and entry points, so legacy apps don't break. The compiler simply puts the new method(s) into the runtime as belonging to that class, and overrides methods with the same signature as in the original code.
an example:
You have a class Bing that outputs to a terminal, but not to a serial port, and now that is what you need. (for some reason). You have Bing.h and libBing.so, but not Bing.m in your kit.
The Bing class does all kinds of stuff internally, you don't even know all what, you just have the public api in the header.
You are smart, so you create a (SerialOutput) category for the Bing class.
[Bing_SerialOutput.m]
#interface Bing (SerialOutput) // a category
- (void)ToSerial: (SerialPort*) port ;
#end
#implementation Bing (SerialOutput)
- (void)ToSerial: (SerialPort*) port
{
... /// serial output code ///
}
#end
The compiler obliges to create an object that can be linked in with your app and the runtime now knows that Bing responds to #selector(ToSerial:) and you can use it as if the Bing class was built with that method. You cannot add data members only methods and this was not intended to create giant tumors of code attached to base classes but it does have its advantages over strictly typed languages.
I think some of these answers at least point to the idea that inheritance is a heavier way of adding functionality to an existing class, while categories are more lightweight.
Inheritance is used when you're creating a new class hierarchy (all the bells and whistles) and arguably brings alot of work when chosen as the method of adding functionality to existing classes.
As someone else here put it... If you are using inheritance to add a new method for example to NSString, you have to go and change the type you're using in any other code where you want to use this new method. If, however, you use categories, you can simply call the method on existing NSString types, without subclassing.
The same ends can be achieved with either, but categories seem to give us an option that is simpler and requires less maintenance (probably).
Anyone know if there are situations where categories are absolutely necessary?
A Category is like a mixin: a module in Ruby, or somewhat like an interface in Java. You can think of it as "naked methods". When you add a Category, you're adding methods to the class. The Wikipedia article has good stuff.
The best way to look at this difference is that:
1. inheritance : when want to turn it exactly in your way.
example : AsyncImageView to implement lazy loading. Which is done by inheriting UIView.
2. category : Just want to add a extra flavor to it.
example : We want to replace all spaces from a textfield's text
#interface UITextField(setText)
- (NSString *)replaceEscape;
#end
#implementation UITextField(setText)
- (NSString *)replaceEscape
{
self.text=[self.text stringByTrimmingCharactersInSet:
[NSCharacterSet whitespaceCharacterSet]];
return self.text;
}
#end
--- It will add a new property to textfield for you to escape all white spaces. Just like adding a new dimension to it without completely changing its way.