This was the day I started to feel my energy wane a little. Maybe it was the rain and the bitter cold we experienced yesterday, but it was definitely more difficult than usual to focus on studies. However, perseverance paid off and I did successfully complete the five chapters (16-20). As is always the case with such things, the sense of accomplishment is great though it can be difficult to see it coming while in the thick of it.
A side-effect of the time it takes to complete these lessons, combined with my regular Japanese studies, is that the actual projects I want to build are not getting the attention I wish to give. I thought I could do both, but it is proving to be too much. Ah, to be 13 again and a bundle of energy, staying up all night drinking Mountain Dew and coding, coding, coding. A veritable NSSponge, so to speak!
For the record, I was never that kid.
Custom Views and Mouse Events
These were difficult chapters for me to work through because I know that Core Image, Core Animation, and the Core Graphics frameworks do far more interesting things than the simple NSImageView class can. That reminds me, I need to track down a good tutorial or book on Core Graphics. It isn’t exactly clear to me when I’d want to use NSImage versus CIImage versus CGImageRef.
One point that is still a little muddled in my brain is about converting mouse event points from the window coordinate system to the custom view coordinate system. Conceptually, I get why I need to do this but it seems like this should be some kind of default behavior, rather than always having to manually convert points between systems. Even Aaron says, “…you will nearly always have to convert the point to the local coordinate system.” So I suppose I’m wondering, “Why doesn’t the mouse event return a point that is already converted to the local coordinate system?” Converting the other way around seems less likely, and therefore shouldn’t that be the one that requires manual conversion?
@property and retains are more confusing to me than I should admit
I feel like a total noob when I say that I don’t get when I need to retain. I also don’t really get when I need to declare a @property. Throughout the book, some ivars get @property and some don’t and it doesn’t seem to affect the performance of the application one way or another.
In Chapter 19, p.270 we create a @property with (retain, readwrite). Then in initWithFrame: we set the ivar with
bgColor = [[NSColor yellowColor] retain];
I thought that declaring the @property with (retain) meant that the generated setter would do a retain. If it does a retain, why do I need to explicitly retain this ivar? In sample code I’ve done in the past, I’ve had NSDictionary objects fall out of scope on me when set in the initialize: or init: method for a custom class. Adding a retain solved the problem, but throughout Aaron’s book I see no retains for NSDictionary objects and everything is working just fine.
Is the solution that alloc/init creates an object that does not require an explicit retain, but autoreleased objects (say from Class methods on Foundation objects) do? I may have just talked out my problem. Thanks for listening! Although I still don’t quite get when to use @property, as it seems that most of the time one wants a setter/getter is because something more interesting is happening than simply setting and getting.
This actually runs counter to what I learned during an object oriented design course taught by Allan Holub who infamously wrote that “setters and getters are evil.” I actually quite subscribe to his notion, “Ask the object that contains the data to do the work.” and would really enjoy applying this principle to my own program structures. However, in reading through Apple documentation I feel that getters and setters are highly encouraged as part of their take on MVC patterns. Perhaps a balance can be found between these two extremes.