Reputation: 111
Should I use NSNumber or string, for saving a simple "playerID number" that now is an integer because I want to save it with Core Data?
In my datamodel I've got a playerID set to Integer 16 but Core Data want's the NSNumber to work. This seems lika a lot of code for "nothing" - example;
NSInteger myValue = 1;
NSNumber *number = [NSNumber numberWithInteger:myValue];
p1.playerID = number;
// Instead of just;
p1.playerID = 1;
// or
p1.playerID.myIntValue;
Just wondering if it would not be easier to set it to string instead and then convert the value (playerID) back and forth as it's needed? Any words of wisdom (experience) on this? Thank's :-)
Upvotes: 2
Views: 2834
Reputation: 6715
On your entity, define the @property
like this:
@property (nonatomic) int32_t playerID;
and then you'll be able to simply set it like
p1.playerID = 1;
This is very elegant and very fast.
In other words, don't define it as being an NSNumber *
. But even if you did, performance would still be excellent. It's just easier to read and write code like this. Also note that with the newest Xcode versions, you can use @(myInt)
in stead of [NSNumber numberWithInt:myInt]
.
Make sure to also check out how to use this for enums: Best way to implement Enums with Core Data (look for my answer).
Upvotes: 10
Reputation: 4452
You can generate your properties with primitive values when creating your NSManagedObject files using Xcode. However, you should know that NSNumber is an abstract class and the runtime class type will depend on what value was used to create the NSNumber.
Upvotes: 0
Reputation: 3517
NSNumber much more effecient to store value in memory than NSString. Because NSNumber uses a runtime facility called tagged pointers to increase speed and reduce memore usage (See more information)
Also I think that NSNumber takes up less space in CoreData than NSString.
Upvotes: 2