2

I'm getting mixed signals as to whether primitive accessor methods (of the form setPrimitive*YourAttribute* vs setPrimitiveValue:*value* forKey:@"*YourAttribute*" in Core Data objects are meant for use with iPhone code or just Mac. On the one hand, the Apple documentation doesn't seem to mention them as available for iOS, just Mac OS X v10.5. On the other hand, they work with my iPhone app's code, albeit with compiler warnings, e.g. "Method xxxx not found (return type defaults to 'id')".

Can someone confirm one way or another?

jscs
  • 63,694
  • 13
  • 151
  • 195
kris
  • 2,516
  • 25
  • 29

2 Answers2

2

In the Overview of the Managed Object Accessor Methods section of Core Data Programming Guide it states that primitive accessors are automatically generated for you, but you will need to declare the properties to suppress compiler warnings. You say using primitive accessors works in your code (even with the warnings) so it seems like it's supported in iOS.

It appears that Apple's documentation pages aren't always rigorous in mentioning a given feature's availability in the various OSes.

pe8ter
  • 1,263
  • 12
  • 10
  • That's the same doc I saw, so I'll mark this as the answer unless/until someone chimes in to the contrary. – kris May 24 '11 at 14:43
  • I followed the documentation to declare my properties and I still get warnings about the primitive accessors not being present. In fact, in Xcode 4 you can create a subclass of an NSManagedObject by selecting the object in the model editor and clicking "Editor->Create NSManagedObject subclass...". When you do this, you'll find the automatically generated code gives the same compiler warnings and the properties are already declared. How does one fix this warnings? – Jason Jul 20 '11 at 18:04
  • In Apple's documentation they give an example of a custom accessor. Apple's example actually declares the primitive methods (but doesn't define them in the implementation, because they are dynamically generated). Given Apple did this, it seems this is the preferred way to fix the compiler warnings. Here's the doc link: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdAccessorMethods.html#//apple_ref/doc/uid/TP40002154-SW1 – Jason Jul 20 '11 at 18:16
  • Hmm... so I followed Apple's example and I still get compiler warnings. Now I get "Incomplete implementation" because I haven't implemented setPrimitive. – Jason Jul 20 '11 at 18:48
  • @Jason see [here](http://stackoverflow.com/a/14444603/128317) for how to suppress the "Incomplete implementation" warning. – mharper May 15 '13 at 20:48
0

You could use NSNumber instead. For bools you would have and [NSNumber numberWithInt:0] for NO and [NSNumber numberWithInt:1] for YES for example. Same logic with integers, doubles, float. It's much easier this way. Your property would be like: NSNumber *myInteger , you would only have to box and unbox it when you retrieve or store it. That's how I would do it.

Fabio Russo
  • 412
  • 6
  • 8
  • Well. Yes you could do that. However if you want for whatever reason to access or set the attribute without KVO notifications being fired the primitive methods are a reasonable solution for this. This is often used in custom setters or getters in `NSManagedObject` subclasses. However take care to implement the right `willAccessValueForKey` and other KVO functions to keep it working. – GorillaPatch May 24 '11 at 08:44
  • You are right, usually you should store numbers as `NSNumber` objects. – GorillaPatch May 24 '11 at 08:45
  • As GorillaPatch noted, it's the ability to suppress the KVO notifications that I'm after. In addition to the good points, your comments are confirming to me that the consensus is that primitive accessors are in fact supports for IOS – kris May 24 '11 at 14:41