How to Find Specific Subclass of Nsmanagedobject

Unable to find specific subclass of NSManagedObject

Update for Xcode 7 (final):
Prepending the module name to the class (as in Xcode 6 and early beta releases of Xcode 7) is no longer necessary.
The Apple documentation Implementing Core Data Managed Object Subclasses has been
updated accordingly.

The Data Model inspector
has now two fields "Class" and "Module" for an entity:

When you create a Swift managed object subclass for the entity, the
"Module" field is set to "Current Product Module", and with this setting
creating instances works both in the main application and in unit tests.
The managed object subclass must not be marked with @objc(classname) (this was observed in https://stackoverflow.com/a/31288029/1187415).

Alternatively, you can empty the "Module" field (it will show "None") and mark the
managed object subclasses with @objc(classname) (this was observed
in https://stackoverflow.com/a/31287260/1187415).

---

Remark: This answer was originally written for Xcode 6.
There were some changes in the various Xcode 7 beta releases with
respect to this problem. Since it is an accepted answer with many
upvotes and links to it, I have tried to summarize the situation
for the current Xcode 7 final version.

I did both my own "research" and read all the answers to both this question and the similar question
CoreData: warning: Unable to load class named. So attribution goes to all of them, even if I don't
list them specifically!

---

Previous answer for Xcode 6:

As documented in Implementing Core Data Managed Object Subclasses, you have to
prefix the entities class name in the Class field in the model entity inspector with the name of your module, for example "MyFirstSwiftApp.User".

Can't instantiate subclass of NSManagedObject

Just came across the same problem: Init method for core data entity not available

Obviously we have to implement the

init(entity: NSEntityDescription, insertIntoManagedObjectContext context, NSManagedObjectContext?)

method in our custom NSManagedObject class. So just add

override init(entity: NSEntityDescription, insertIntoManagedObjectContext context: NSManagedObjectContext?) {
    super.init(entity: entity, insertIntoManagedObjectContext: context)
}

to your entity class and it will work.

NSManagedObject subclass outside of managed object as a normal object

2nd paragraph of the NSManagedObject class documentation's overview:

A managed object is associated with an
entity description (an instance of
NSEntityDescription) that provides
metadata about the object (including
the name of the entity that the object
represents and the names of its
attributes and relationships) and with
a managed object context that tracks
changes to the object graph. It is
important that a managed object is
properly configured for use with Core
Data. If you instantiate a managed
object directly, you must call the
designated initializer
(initWithEntity:insertIntoManagedObjectContext:).

From the documentation of the method:

Important: This method is the
designated initializer for
NSManagedObject. You should not
initialize a managed object simply by
sending it init.

The documentation is actually very good.

You do not want to try to use an NSManagedObject outside of a viable CoreData stack. NSManagedObjects are quite explicitly designed to work within a correctly configured Core Data environment. If you need a temporary instance, you can either create an in-memory store or create one in your regular store and just don't save the changes without deleting it first.

CoreData NSManagedObject subclass - Expected identifier

Well... I solved my problem.
I had a bracket somewhere in my main file on a place it shouldn't be.

So. My experience with this error is looking after some misplaced letters :)

How to add attributes to an NSManagedObject subclass created by the data model file?

After changes to the Core Data entities, you must recreate the managed object subclass
files via "Editor -> Create NSManagedObject Subclass …" from the Xcode menu. Manually
editing these files only bears the danger of introducing errors.

Alternatively, use tools like "mogenerator" to create and update the files automatically.
See (for example) Mogenerator and Xcode 4 advantages/disadvantages for a comparison between "mogenerator" and the built-in Xcode
file generation.

Why exactly would one subclass NSManagedObject?

I still don't really get what subclassing NSManagedObject is for - what role does it play?

Convenience for the developer - in terms of CodeSense, shorter syntax, and some compile-time checks that help thwart misspellings of keys.

so what can I do with NSManagedObject? What are the restrictions, must-follow guidelines, and what aren't restrictions?

The UI built into Xcode will make the NSManagedObject subclasses for you - you really don't need to do it by hand - but, basically, they are just NSManagedObjects with some properties tacked on. Instead of using @synthesize or such, you use @dynamic and Apple takes care of the rest for you - hooking up those properties to getters/setters which mimic what you would normally do with a "bare" NSManagedObject.

I'm trying to make a little box drawing program to learn Core Data, and I'm thinking of adding "draw" methods to a subclass of NSManagedObject so that a view can just tell them to draw for itself - is this permitted?

You could.... but I wouldn't. This sounds like bad design - try to keep your Model and Controllers separate.

Model objects shouldn't contain business logic / drawing code. Use the model simply as the "state" of your application. Make something else responsible for the drawing. Plus, while I can't say this with absolute authority, I believe there is some overhead if you're dealing with updating / retrieving info from an NSManagedObject.

(Basically, it's like dealing with an NSDictionary... sorta. It's less efficient to grab items out of a dictionary than it is to access an ivar.)

For an app that does things like drawing - you'll probably want to avoid that overhead by making a structure for your in-memory things, and possibly a second, similar structure for persistence/serialization (like to CoreData).

So, my question in one sentence would be, what's the "real" difference
between subclassing NSManagedObject and any other class - what does
Core Data do with it?

I would say - don't subclass NSManagedObject by hand at all - use what Xcode gives you. If you want more (other than maybe a custom constructor) then you're probably barking up the wrong tree.

EDIT:

I think there might have been some confusion about what I meant when I said "don't subclass NSManagedObject by hand at all"

To elaborate, and incorporate one of the responses:

Start with the data model designer in Xcode, create your models, and use the following menu option:

Then, you could modify the generated class to include custom:

• Constructors
• Data Conversion Methods
• Validation
• Formatting
• Sort Descriptors
• Filters

If your use case doesn't fit in that list, you should really seriously think about putting it somewhere else (as in your example with the "Draw" method).

All of those things mentioned above could be tacked on to an NSManagedObject subclass which was created for us by Xcode (we didn't create "by hand") - and they all revolve around dealing with the data directly (formats / conversions / etc) and/or around pulling the data out of Core Data (filters / sorting).

They don't add iVars, they don't perform any complicated operations outside of the scope of data storage and retrieval.

---

Related Topics