Coding under the Hammer
NSNumber: What is the point ?
The first time you see NSNumber your probably say to yourself “What is the point of NSNumber? I already have int, float, double etc”. Although this may be true, there are many occasions when you actually need to use NSNumber.
1. Adding a number to an array
NSArray (NSMutableArray etc) does not allow you to add primitive types to it. This is because an NSArray is simple a set of pointers to the Objects you add to it. This means if you want to add a number to the array, you first have to wrap it in a NSNumber.
NSArray *numbers=[NSArray arrayWithObject:[NSNumber numberWithInteger:2]];
2. Number type conversion
NSNumber allows you to easily convert the type of a number e.g. from an int to a float
NSNumber *number=[NSNumber numberWithInteger:2];
float floatValue = [number floatValue];
3. Perform selector calls
Once you have used Objective-C for a while you may come across performSelector. This allows you to carry out advanced techniques like performing a selector after a given delay.
[magicObject performSelector:@selector(performMagicWithNumber:) withObject:[NSNumber numberWithInteger:2] afterDelay:1.0];
This the equivilant of doing the following without a delay:
[magicObject performMagicWithNumber: [NSNumber numberWithInteger:2] ];
4. Persisting Objects (CoreData)
Archiving Objects is a lot easier than archiving primitive types, as NSNumber inherits from NSObject you can use various archiving and de-archiving methods on them. CoreData actually requires you to use NSNumber for persistent storage. One thing that may not be obvious at first glance, is that CoreData (and Objective-C) considers BOOL as a NSNumber.
Summary:
You may write the best selling application on the Appstore and never use NSNumber, but if you need to persist your objects or you need access to the various performSelector calls, NSNumber is obviously the way to go.
about 8 months ago
Hello, can you please post some more information on this topic? I would like to read more.
about 8 months ago
Sure, what area are you particularly interested in ?
about 8 months ago
First, thank you so much for posting this topic. It has helped me immensely with a persistence function I am creating. I am a traditional procedural programmer. I’ve been programming for 10+ years, mostly VB. I’m desperately trying to learn OOP but it’s not coming as fast as I hoped. Primarily because many of the posts that I see make assumptions about OOP that may seem obvious to a OOP coder but not so obvious to a procedural programmer. I’ve been reading several books on the subject and I sure eventually the pieces will snap into place- however right now they are all hovering up in the air.
I am familiar using performSelector calls to call methods, but I don’t understand how NSNumber is involved with that call? Please explain more on that.
Also, I’m having a lot of difficulty with understanding the hand off from one class to the next. Since, unlike procedural programming where the computer waits for a function to complete before continuing with the next line of code, Objective C just keeps on going regardless if the method(function) has completed.
Thanks in advance for your help!
about 8 months ago
Hi John,
So if you wrote the following:
[magicObject performSelector:@selector(performMagicWithNumber:) withObject:[NSNumber numberWithInteger:2] afterDelay:1.0];As a C function:
performMagicWithNumber(magicObject , 2);Obviously you don’t have the delay there, and your acting upon the “magicObject”
I think your confusing event driven programming, with OO programming (Cocoa Programming is both).
In terms of the hand off between objects in OO programming, as soon as you call a method on a object, that method is carried out. Once that method has completed control returns to the object that called that method. This is exactly the same way that functions work in procedural programming.
Classes are simply structs under the hood, and methods are simply functions that can only be called on a single class. OO programming just makes code cleaner and more maintainable.
Most Cocoa applications are also event driven, so when you touch a iPhone’s screen it triggers off a chain of events. But unless the application is threaded, this event has to wait until the current thread is idle until it can be carried out. Things still get queued like in procedural programming, but obviously events can come in in a variety of orders if an application is being driven by the user.
about 8 months ago
It’s a pity that people don’t realize the importance of this information. Thanks for posing it.