4
votes

We've got a model in our iOS with an id property. Here's what we're currently using (this is iOS 5 by the way).

 @property (nonatomic, assign) int userID;

Seems to be working fine so far. I'm wondering if this will cause any problems going forward.

Example: I understand that this means that the ID property itself could not be stored into a plist. However, this is a property of an NSObject. If we were storing anything into a file/core data/nsuserdefaults/whatever it would likely be the entire object and not just this property.

I guess my question is ... are we going to cause ourselves any problems by storing this as an int as opposed to an NSNumber?

Secondly, what would be the difference in storing this as an NSInteger instead. I understand that it's just a type def to either long or int depending in the architecture. Since we're only targeting iPhone does it matter that it's just set to int? Doesn't seem like it would make any difference in that case.

3

3 Answers

6
votes

I guess my question is ... are we going to cause ourselves any problems by storing this as an int as opposed to an NSNumber?

That really depends on what you're going to do with this value. If you'll want to treat it as an object (for example, so that you can store it in an NSArray or NSDictionary) NSNumber may be convenient. If you just want to keep track of the value, and int works for you, then it's fine to use int.

Secondly, what would be the difference in storing this as an NSInteger instead. I understand that it's just a type def to either long or int depending in the architecture. Since we're only targeting iPhone does it matter that it's just set to int?

I'd go with NSInteger (and NSUInteger). Using those types, your code will automatically use the appropriate size for the architecture you're compiling for. You may only be targeting iOS, but you're probably running your code on the iOS simulator, which runs on MacOS X. So that's two architectures right there -- and you don't know what may happen with iOS in the future.

0
votes

The only limitation I can think of is if int=0 is a valid value or int not having a value (null) is an important use case.

Since ints are always initialised with 0, you wont have a situation where you can check for non-existence of that property.

In your case say you wanna test if user_id is present or not then its not possible with primitive data type like int since it will always have a value.

In another scenarios 0 could be a valid value (or even in your scenario - Steve Jobs was joked to be Employee Number 0 in Apple in many pop culture references). In that case int getting initialized with 0 every time might be an unwanted side-effect you will have to deal with.

-1
votes

It is quite normal to use an int as a property in a subclass of NSObject.

Depending on your platform, NSInteger could be an int or a long but other than that, it doesn't matter if you use int or NSInteger and can be used interchangeably as long as the value doesn't exceed the limit of an int.