Learn Objective-C on the Mac - Mark Dalrymple [115]
A couple of things to point out: you may have noticed that we’re using release and retain here, even though we’re using garbage collection. This is partly due to old authors having deeply ingrained habits that are hard to break, but there are practical reasons for doing so as well. In this case, this small class is something that one might want to port over to a platform where garbage collection isn’t available, such as the iPhone. With the balanced retain/release calls in place, moving this code to the iPhone is as simple as changing a few class names (for example, NSView and NSColor become UIView and UIColor). The other thing to note is the [self setNeedsDisplay:YES] call. we’ll get into this more in later chapters covering drawing in Cocoa, but the basic idea is that when you want to draw some content in an NSView, you call this method, which sets a flag, and when your application is done processing whatever event it’s currently handling, it will look through the open windows to see if anyone has been flagged for redrawing, which leads to the eventual calling of the drawRect: method.
Speaking of which, the only other method we need to implement in this class is the drawRect: method itself.
Try not to get too caught up in the details here. It’s enough if you read the comments, and trust that the code is doing what the comments claim it’s doing. After going through some of the later chapters where we’ll be dealing with graphics, this will start to make more sense.
The final piece we need to add for this class to work is a conversion routine so that the NSColors that are picked by the user in the color panel can be converted to the CGColorRefs that are necessary for the Core Graphics functions. For some reason, Cocoa doesn’t include any one-line function or method calls that do this, but the following function does the trick nicely. Insert this near the top of the .m file. Anywhere above the drawRect: method is fine, but, for the sake of keeping things structured, we’d recommend putting it just above the @implementation block, to make it clear that this function is not a part of the class.
With that in place, the ColorBlendView class is complete. Save your work and click Build, and it should compile cleanly. We’re only asking you to click Build now to make sure that no typos have crept in up to this point; we haven’t set up the GUI yet, so there’s no point hitting Build & Run right now.
Adding Blended Colors to the GUI
Now it’s time to add the blended color swatches to our document window. Let’s start by adding an outlet for each of them to the MyDocument.h file. Each of the new outlets shown here will end up connected to an instance of ColorBlendView. We’re also adding a line near the top with an @class declaration, which simply tells the compiler that the next token (ColorBlendView) is the name of a class. That’s just enough information to let the compiler deal with instance variables and method arguments that are pointers to instances of that class, without importing the class’ header itself. Using these forward declarations consistently in your header files can give you slightly better compile times, and also makes your header files less brittle, because they have fewer dependencies on one another. In your implementation files, however, where you’re going to call methods on these classes, you’ll need to import the header file.
Now go back to MyDocument.xib in Interface Builder, and make the window bigger, about 350×500, leaving the two color pickers at the top. Find a CustomView (really an instance of a plain old NSView) in the Library, drag it into the window, and use the Identity Inspector to change its class to ColorBlendView. Then resize the ColorBlendView to about