NSDecimalNumber is Objective-Câ€™s solution to numbers that need to be very precise. The documentation defines it as:
NSDecimalNumber, an immutable subclass of NSNumber, provides an object-oriented wrapper for doing base-10 arithmetic. An instance can represent any number that can be expressed as mantissa x 10^exponent where mantissa is a decimal integer up to 38 digits long, and exponent is an integer from â€“128 through 127.
If you are dealing with currency at all, then you should be using NSDecimalNumber. However, since it is immutable and definitely not a primitive then it is difficult to use right? Well â€” yes â€” a bit. But if you do not want to see your $9.50 item displayed as $9.49999994 or something then you are better off using NSDecimalNumber right from the beginning. Otherwise you are going to be converting to it later and that is a LOT more painful.
For the past five or six months, I have been developing an application for the Mac that I intend to release for sale in the near future. Though you could probably call me a switcher, to my credit I was a Mac user all through college and would have remained so had the job market been a bit more supportive of that desire when I finished school, but all along I’ve wanted to become a Macintosh developer. That time has finally come.
Key Value Observing/Key Value Coding (KVO/KVC) is probably one of the most powerful and most under-utilized features of Objective-C. Here are a couple of examples of how to get the most out of it
When a call is made on an object through Key Value Coding such as [self valueForKey:@"someKey"], numerous attempts are made to resolve the call. First, the method someKey is looked for. If that is not found then the iVar someKey is looked for. If neither of those are found, then one last attempt is made before presenting an error. That last attempt is a call to the method -(id)valueForUndefinedKey:. If that method is not implemented then an NSUndefinedKeyException is raised.
valueForUndefinedKey: is designed so that when you request a value from an object using -(id)valueForKey: the object has a last chance to respond to that request before an error occurs. This has many benefits and I have included two examples of those benefits in this post–Core Data Parameters and Data Formatting.
System programming is one of the more interesting topics to me because it seems like it’s the hackers domain. When I first got into programming I always wanted to see if I could make the computer do something that nobody else anticipated it could do. I think it was probably just from watching too many hacker movies. Even the Matrix (the first one, not those other two contorted kill joys) had this affect on me that somehow I could beat the system because as Morpheus put it,
I’ve seen an agent punch through a concrete wall. Men have emptied entire clips at them and hit nothing but air, yet their strength and their speed are still based in a world that is built on rules. Because of that, they will never be as strong or as fast as you can be.
Man! I loved that movie the first time I watched it. A world without rules? Or more specifically a world where you set the rules by your most awesome hacker powers. Sweet!
But alas, as I’ve proceeded and matured (I hope) in my programming abilities, this whole area has become much less glamorous as I realize that hacking is really about finding vulnerabilities in other people’s code. That’s really not that exciting to me, but system level programming remains interesting and a good place to start is to look into who the users are on my system. Time to use Identity Services. And in this intro I’ve written a very basic password cracking system.
Error handling is rarely fun. I find myself often re-coding a method after I realize that I need to handle one error condition or another. Usually, error handling involves either try/catch or some return code strategy. Neither of those is pretty or easy to maintain. For Objective-C development, however, there is another option — NSError.
When developing an application in Objective-C and using Cocoa, there is a lot of “magic” that happens in the background. As we get more comfortable with the language and the APIs, we begin to discover the source of that magic and understand not only WHY it works but HOW it works.
One of those areas is the initialization and callbacks from the nib files to my code. Normally, when I want a controller to do something after the NIB/XIB has loaded, I add the method -(void)awakeFromNib and know that I will receive a call when all of the connections into the NIB/XIB are complete. But on what object does this get called and how?
I am currently working on an application that needs to set markers in audio and video tracks. While it’s easy to find a marker visually in the video tracks, it wasn’t quite so clear as to how to set a marker in an audio track. In this tutorial, I’ll demonstrate how to create an audio scrub utility that will play a short audio clip when you drag an NSSlider. It shows the current time code of the track while you update the slider.
In our continued efforts to demonstrate different ways to use Core Animation, we have noticed different effects you see in OS X itself that present an interesting challenge to duplicate. In a previous post, we demonstrated how to shake a login window similar to the way that OS X shakes the login window when the user enters the wrong password. This time, we’re going to demonstrate how to do what we’ve dubbed the Dashboard Effect.
I’m not sure this is the best name for it as some people may think we mean the ripple effect you see when you drop a new Dashboard widget on the screen, but what we mean is the way in which the Dashboard widgets that are already employed in Dashboard fly in and out of view when you enable and disable Dashboard. Enable Dashboard now and watch your widgets fly in from offscreen. Then disable it and watch the widgets fly out again. This is what we mean by the Dashboard effect and this is what we set out to duplicate.
A question that I have seen pop up a few times is how to build a Wizard in Cocoa. Having thought about that question a bit I realized that a better answer to it is — how to build a wizard in Cocoa using Core Animation.
The basic concept behind this project is to present a window to the user that will walk them through a list of options. To accomplish this task, I created a number of NSViews that will be presented to the user in order so that they can make the decisions needed. To make this a little easier, I have extended NSView to create MSZLinkedView. The added functionality in this subclass is that the view has a reference to the previous and next views in the wizard. These references are set in interface builder directly so that I do not have to worry about them in code.
This article is inaccurate.
The writer was smoking crack or something when he wrote it and has not been able to duplicate his tests since. This article is left here for historical reasons.
One of the things about Objective-C that I find extremely useful is the ability to resolve a method call at runtime. In addition this same functionality allows us to do some fairly creative things with callbacks, passing messages between threads, etc.
However there is a bit of a trick when it comes to passing primitives though some of these methods. For example, one method that I use quite frequently is performSelectorOnMainThread:withObject:waitUntilDone:. How exactly does one pass a BOOL or an int to this method?
Core Animation is really the buzz among Cocoa developers these days and we are no different from the rest. Learning to do simple fades and frame movement is trivial, but figuring out the more complex effects is quite a challenge. We decided to venture out and try to create some really concise examples of effects you might find used in Leopard. And while these effects may not be done with Core Animation where they are found in the OS, we’ve set out to duplicate them in Core Animation regardless. Our first challenge? Shaking a login window.
This post is in response to a few queries that I have received regarding my last post showing an NSOperation example. One of the questions raised that I will focus on is my -(void)dealloc method in the NSOperation subclass. The questions boiled down to:
Why are you using releases at all. Garbage collection is the future!
You should be just doing [self setVar:nil] instead of that [var release], var = nil; crap.
Threading is hard in any language. And what is worse, when it goes wrong, it usually goes wrong in a very bad way. Because of this, programmers either avoid threading completely (and refer to it as the spawn of the devil) or spend a LOT of time making sure that everything is perfect.
Fortunately, Apple has made a lot of progress in OS X 10.5 Leopard. NSThread itself has received a number of very useful new methods that make threading easier. In addition, they have introduced two new objects: NSOperation and NSOperationQueue.