#nsnumber

[nsfail]

Calling integerValue and unsignedIntegerValue on NSDecimalNumbers created from strings (including those using KVC) yields inconsistent results.

This bit someone trying to use key-value coding to get the average of a given number out of an array of items with an NSUInteger property.

The NSNumber which came out of the @avg.value KVC method was of value 588.33333333333333333333333333333333333. The person then tried to access this value by calling both average.integerValue and average.unsignedIntegerValue.

On this person's computer, which was running Mavericks, the average integer would be 588. On my computer, running Yosemite, the average would be zero. After quite a bit of futzing about, we discovered that NSDecimalNumbers created from a string respond differently to being converted to an integer depending on the length.

http://openradar.appspot.com/20211159

[whoistuanhai]

Literal syntax

Các class NSString, NSArray, NSNumber, NSDictionary thuộc Foundation framework. Chúng có cú pháp dài dòng giống như đặc trưng của ngôn ngữ Objective-C. Tuy nhiên, từ Objective-C 1.0 đã xuất hiện literal syntax giúp việc viết code ngắn gọn và dễ đọc hơn.

Literal NSString

Không dùng literal syntax:

NSString *someString = [NSString stringWithFormat:@"some String"];

Literal syntax:

NSString *literalString = @"literal String";

Literal NSNumber

Không dùng literal syntax:

NSNumber *someNumber = [NSNumber numberWithInt:1];

Literal syntax:

NSNumber *literalNumber = @1;

Không chỉ với kiểu dữ liệu int, literal syntax còn dùng với tất cả các kiểu khác mà NSNumber có thể đại diện.

NSNumber *intNumber = @1; NSNumber *floatNumber = @1.0f; NSNumber *doubleNumber = @3.14217; NSNumber *boolNumber = @YES; NSNumber *charNumber = @'a';

Literal syntax còn dùng được với một expression:

int x = 2; int y = 3.14; NSNumber *expressionNumber = @(x * y);

Literal NSArray

Không dùng Literal syntax:

NSArray *animals = [NSArray arrayWithObjects:@"cats", @"dog", @"mouse", @"bird", nil];

Literal syntax:

NSArray *animals = @[@"cats", @"dog", @"mouse", @"bird"];

Không chỉ khởi tạo array, việc lấy ra phần tử của NSArray với literal syntax (subscripting) cũng ngắn gọn hơn:

Không dùng Literal syntax:

NSString *dog = [animals objectAtIndex:1]

Dùng literal syntax:

NSString *dog = animals[1];

Lưu ý, khi tạo NSArray bằng cách sử dụng literal syntax, nếu một phần tử bằng nil, một exception như sau sẽ bị xổ ra:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[1]'

Điều này dẫn đến một vấn đề nhỏ khi sử dụng literal syntax. Ví dụ:

NSString *string1 = @"string1"; NSString *string2 = nil; NSString *string3 = @"string3"; NSArray *arrayA = [NSArray arrayWithObjects:string1, string2, string3, nil]; NSArray *arrayB = @[string1,string2,string3];

Trong trường hợp này, arrayB sẽ khiến exception bị xổ ra do có phần từ nil trong mảng, arrayA vẫn sẽ được tạo và sẽ chỉ có một phần tử là string1 do hàm mà arrayA dùng để khởi tạo sẽ dừng khi nó bắt gặp nil nhưng do string2 là nil nên nó dừng sớm hơn dự kiến ban đầu.

Sự khác nhau ở trên có nghĩa là literal syntax an toàn hơn trong việc khởi tạo mảng do nó bắn ra exception khi có phần tử nil trong mảng còn hơn là việc tạo ra mảng mà có ít phần tử hơn dự kiến. Exception được bắn ra sẽ giúp tìm ra lỗi dễ dàng hơn.

Literal NSDictionary

Không dùng literal syntax:

NSDictionary *personData = [NSDictionary dictionaryWithObjectsAndKeys: @"Tuan Hai", @"firstName", @"Tran", @"lastName", [NSNumber numberWithInt:24], @"age", nil];

Nhìn khá loạn, do thứ tự value-key của cách này. Sử dụng literal syntax:

NSDictionary *personData = @{@"firstName" : @"Tuan Hai", @"lastName" : @"Tran", @"age" : @24};

Rõ ràng, dùng literal syntax ngắn gọn hơn và cũng giống với cách ta thường nghĩ về NSDictionary đó là key-value. Tương tự NSArray, NSDictionary cũng xổ ra exception khi có phần tử nil trong lúc khởi tạo bằng literal syntax.

Cũng giống như NSArray, NSDictionary có thể được truy cập bằng literal syntax. Cách cũ:

NSString *firstName = [personData objectForKey:@"firstName"];

Literal syntax:

NSString *firstName = personData[@"firstName"];

NSMutableArray và NSMutableDictionary

Giống cách truy cập các phần tử bằng index trong NSArray hay key trong NSDictionary, ta có thể set giá trị của nó nếu object là mutable. Cách cũ:

[mutableArray replaceObjectAtIndex:1 withObject:@"dog"]; [mutableDictionary setObject: @"Tuan Hai" forKey:@"firstName"];

Literal syntax:

mutableArray[1] = @"dog" mutableDictionary[@"firstName"] = @"Tuan Hai";

Hạn chế

Khi tạo một mutable object bằng literal syntax, cần phải gọi thêm hàm mutableCopy:

NSMutableArray *mutableArray = [@[@1, @2, @3] mutableCopy];

Tuy phải gọi thêm một lời gọi hàm nhưng lợi ích của việc dùng literal syntax lớn hơn hạn chế này.

Ghi nhớ

Sử dụng literal syntax để khởi tạo string, array, number, dictionary vì cú pháp ngắn gọn, rõ ràng.

Truy cập phần tử của array và dictionary bằng subscript

Đảm bảo không có phần tử nil được thêm vào array và dictionary khi sử dụng literal syntax.

[goodanswerbiz]

Fixed How to convert an NSString into an NSNumber #dev #it #asnwer

Fixed How to convert an NSString into an NSNumber #dev #it #asnwer

How to convert an NSString into an NSNumber

How can I convert a NSString containing a number of any primitive data type (e.g. int, float, char, unsigned int, etc.)? The problem is, I don’t know which number type the string will contain at runtime.

I have an idea how to do it, but I’m not sure if this works with any type, also unsigned and floating point values:

long long scannedNumber; NSScanner…

View On WordPress

[g8production]

Data type in a NSNumber

Into a NSNumber you can put primitives like int, bool, float, etc... They are translated in a Objective-C object (the NSNumber).

If you want to get the type of data contained into the NSNumber, the objCType method can help you.

- (const char *)objCType

It returns a C string (const char *) containing the Objective-C type. The objCType method is declared in the NSValue class.

Finally, using the strcmp function you can understand if the data type. How is explained below.

const char *t = [myNSNumber objCType]; if (strcmp("i", t) == 0) { NSLog(@"is a int"); return; } if (strcmp("f", t) == 0) { NSLog(@"is a f"); return; } if (strcmp("d", t) == 0) { NSLog(@"is a dobule"); return; } if (strcmp("c", t) == 0) { NSLog(@"WARNING! is a boolean or a char!!!!!"); return; }

That's all!

[script-ease]

[cbowns]

API Smell: NSNumber

NSNumber is an Objective-C object wrapper for C and Objective-C's scalar values, such as BOOL, float, NSInteger, et cetera. It's commonly used when one needs to store a scalar in an Objective-C collection: NSNumber can be used to "box up" the value and store it in an NSArray or NSDictionary. Most Objective-C developers see NSNumbers when using NSJSONSerialization, which uses NSNumbers to store numeric values in the data structures it's decoded from (or is encoding to) JSON.

NSNumber should only be used in that capacity: as intermediate storage for a scalar while it's in an Objective-C collection. It shouldn't be passed as a method parameter, be assigned or returned by a property on a model object, or be used as a key in an NSDictionary.

NSNumber’s weakness lies in the ambiguous type of its value. If you receive NSNumber *aNumber as a method parameter and want to know its scalar value, what type should it be evaluated as? Is it correct to treat it as a YES/NO, and send it [aNumber boolValue]? Or perhaps it's a floating-point value and should be sent [aNumber floatValue]? Without introspecting the Objective-C type encoding of an NSNumber, a glance at its value doesn't hint at the original value. Consider an NSNumber whose integerValue is 1. Is it a signed or unsigned integer? Is it a boolean? Or is it a float that happens to be 1.0?

(Lucas Newman pointed out that it's technically possible to call objCType on an NSNumber instance to retrieve the type encoding of its original value. However, this should be considered a technique of very last resort.)

If you're passing an NSNumber to a method, pass it as the appropriate scalar value rather than relying on the recipient knowing (or guessing) the correct underlying type.

If you're using an NSNumber as a dictionary key, convert it to an NSString. Keys don't normally represent any particular numeric value: if they do, an NSArray may be a better type of storage.

JSON and Model Objects

When an NSNumber is returned as part of a JSON response, it should be converted to a more appropriate type as soon as possible. An evaluation of the value's final use will help. If the JSON represents that field as a number (as opposed to a string that happens to contain a numeric value), evaluate how it's used by the client. If the client makes decisions based on its numeric value, consider declaring an enumeration of valid values:

typedef NS_ENUM(NSInteger, MPObjectType) { kMPObjectTypeInvalid = 0, kMPObjectTypeUser, kMPObjectTypeGroup };

Once the valid values have been enumerated, a model object created from a JSON response should store its value as a scalar property:

@property (nonatomic, assign) MPObjectType objectType

instead of an NSNumber:

@property (nonatomic, strong) NSNumber *objectType.

Model objects can declare a public property like the one above, and use the NSNumber instance internally in dynamic getter and setter implementations. Here's an example model object with a BOOL property that's backed by an NSNumber. JSON responses may contain a literal number for an object's ID field. As a rule of thumb, consider this a bug. This integer value typically originates from a relational database being used for storage by the server, and a naïve JSON encoding by the server passes that value along as a numeric field rather than a string. Its type should nonetheless be treated an implementation detail of the database. A client should represent this ID as an NSString and should make no attempt to inspect its numeric value. This ID string will function correctly as a key in an NSDictionary to store and retrieve an object, and will return the correct result when compared to another object's ID with isEqual:. By clearly indicating the ID as an opaque value with no intrinsic numeric meaning, it helps avoid unwise or untenable uses of the ID, such as sorting objects by the numeric value of their IDs when they need to be ordered. (There's usually a more appropriate sort; in this case, IDs typically increase over time, so they should be sorted by the objects' creation dates instead.) An objective evaluation of one's use of NSNumber makes for clearer and more future-proof code. NSNumber should be used only as a temporary representation of a numeric value. If an instance of NSNumber has numeric meaning, it should be converted to a scalar value; otherwise, it should be converted to an NSString.