NSNull versus (null)

OK, the book says that an NSNull instance (=null) can be used to represent "nothingness," e.g. in a NSMutableArray. But it looks like this will be the value of an NSDate instance variable that you declare but fail to implement (by which I mean that you fail to assign any value to). At least, its descriptor will return "(null)."

But then it looks like I was wrong; it's just a mere case of homonymy: (null) is not null. Even though my unassigned NSDate instance entryDate was described as "(null)" by its description method, it's not an NSNull instance, since

[entryDate isEqual:[NSNull null]]

returns 0. And NSNull has only one instance, so every null would be "equal" to each other. Right?

So what's this "(null)"??! NSDate's documentation doesn't say anything about it, and neither does NSObject's.

initWithFormat: vs. stringWithFormat:

OK, I get it: NSString's initWithFormat method is an instance method, whereas stringWithFormat is a class method.

But the book says that the latter returns an autoreleased string object. OK, cool. But why does the documentation for either method or the class fail to mention that?!

Is there a rule of thumb that class methods other than alloc, new, copy or mutableCopy always return autoreleased objects (as Aaron suggests)? If so, how reliable is this rule? Would be nice to know.

I know that this point is mostly moot with garbage collection in Objective-C 2.0, but still. I want to learn the good ol' laborious retain counting way as well (and also, I hear GC isn't suitable in all circumstances).

By the way, I'm at Chapter 3. Building a Foundation tool.

The RandomNumber app

I had already started to read the book before, and liked it a lot. I think I completed the first app it teaches, RandomNumber. So I decided to read the specs and create it without looking in the book. I actually managed to. As I suspected, I had to browse the documentation a lot (especially for the random functions), but in the end, my little app did build.

Let me just say that I'm not fully satisfied with the documentation facilities built in Xcode. I will collect my thoughts on it as I gain more experience (and probably realize that lots of things that I didn't think were there are in fact there), and do a separate post on the subject later. All that I know is that, as a beginner, I could use a bit more hand-holding.

So anyway, here's how my version of the app differred from Aaron's.

Mine displayed the random number in a text field, not as a label. More importantly, I complicated things a bit, as I already applied the MVC concept to this simple little thingy.

While in Aaron's version (note that it is the first-ever app he has his readers build), the random number generation is done in the controller, my version actually has a model class, and the random number is one of its properties. Random number generation (as well as "seeding," or initialization) is performed in the model, all the controller does is call these methods, and update the text field with the randomNumber property of the model class.

I guess this is overkill, but then at least it's MVC. And the model preserves state, too.

Due to my lack of experience, I had no idea how the model object should be created. I decided to have only one instance throughout the life cycle of the app, and I had the controller (which is serialized in the nib, if I'm not mistaken) allocate and initialize it as soon as it awakes up from the nib.

I was a bit surprised when I found out (from sample code) that there's no need to call [super awakeFromNib] when implementing that method, if I'm subclassing NSObject, but then I confirmed that to be the case in the documentation.

I guess I could also serialize my model object in the nib file? Um, maybe not. This doesn't seem to be recommended. So I'll leave it at that.

Just started "Cocoa Programming for Mac OS X"

This book has been recommended to me in several forums, so I bought it last year, decided not to wait for a Leopard version. (Is there a Leopard version coming at all? Maybe I'll find out by registering the book, as recommended. OK, I've just registered the book, only to find out that my benefits for registration happen to be nada. So, no information on that. Sorry…)

All in all, I like the book, and am very excited as I go in and try to learn Cocoa. Wish me luck.

Some more bitching: editing application package info

OK, software development is supposed to be geeky, but why is this so incredibly tedious? I mean, I just want to enter the version number for my app. It's something every app needs. So why do I have to type stuff like CFBundleShortVersionString, instead of, say, filling in a text field somewhere?

Is CodeSense dumb? Or am I?

OK, this is weird. I declare a method in the header file for a class. Then I switch over to the implementation file. I want to implement the method… and I need to type out its name. CodeSense doesn't offer to autocomplete it. Is that a feature? Or can't it read the header file?

Then, when I begin to type an expression that sends a message, as in [myObject performMethod], why doesn't CodeSense offer performMethod as a prominent autocompletion option? And when I want to access a property with the dot syntax… No CodeSensing for me. Am I supposed to keep in mind all method and instance variable names I declared, at all times, and get no help?

Houston, we have Leopard

I've put off diving too deep into Cocoa until Leopard was out. I installed the new OS the day it came out; today, I even got the internet working (I had to buy a router, as Leopard seemed to be unable to get an IP address from my ISP on its own, needless to say, that's made me pretty disappointed and frustrated).

I read Apple's PDF on Objective-C years ago. I know some C, though I'm not a C programmer by any stretch of the imagination. I've followed some tutorials, even read a couple of Cocoa books, so I'm vaguely familiar with the simplest concepts, but I still find the learning curve that's ahead of me a bit intimidating.

I followed through the CurrencyConverter tutorial, though for some strange reason, the version included with the Leopard dev tools was not updated for the new OS. I couldn't help noticing how different things are now, even at such an elementary level.

For example, I'm no longer supposed to create classes in Inteface Builder, and then import them into Xcode. Looks like classes are now solely being generated by manually writing code in Xcode. I can't say I like that; though real programmers probably rejoice. I guess I need to grow fond of typing everything by hand, even boilerplate code, if I want to be a real programmer.

OK, now that I have internet, I can follow the updated tutorial. I'm going in.