Totally missed on that one. The small amount of work I’ve previously done in Cocoa Objective-C was entirely with KVB – Key-Value Binding – and I’d not touched KVC/KVO.

Just got around to watching the Stanford video that covered that topic and, while I completely missed the distinction between KVC/KVO and KVB, I was at least right that KVB does not exist in Cocoa Touch.

Through reflection in Java you can manage KVC. Not sure about KVO – never had any call to use it. I’ve never had much use for KVC in Java, except when being handed unknown-typed objects. I guess to remains to be seen when it will be handy in Objective-C.

Seems like (and my study of Cocoa on the Mac is hazy) that KVC isn’t implemented (or at least not in the same fashion) for CocoaTouch.

If I recall correctly, under an NSSlider, you could assign a binding between the value property of the slider to an ivar on the controller class and get direct updates between one to the other.

A UISlider, on the other hand along with the other UIControls (unless I’m missing something) doesn’t allow you to bind between properties of the control and properties on the controller. It only allows you to bind the control object itself to an ivar representation of the same control class property on the controller.

Subtle difference, I suppose…

It seems like I read somewhere that the xib files are actually being used to instantiate the property classes in the controller that are designated IBOutlets, so it’s not so much a binding between two objects, but actually using an alternate mechanism to instantiate the object. (Or perhaps it just sets the pointer to the same address?)

I’m following Stanford U’s class, though I’m only just beginning assignment 3. Look forward to that post.

It’s got tab controllers, navigation controllers, data entry, custom modeled objects… and so far, I’ve only completed about 50% of it, and, more tellingly, I’ve restarted it from scratch about 3 times.

So, I’m far from familiar with Objective-C, and more than willing to admit I’m biased, through familiarity, towards Java’s syntax.

Helpful as Xcode is with syntax assist, I’m going to give the node to Eclipse, for putting more information at your fingertips. That’s also playing a factor in my ease (or stumbling around) in picking up Objective-C.

That reminds me, I should talk a bit about Stanford U’s iPhone class. Time for a post.

At first the syntax difference with both C and Java threw me (I always used this in Java but it has to be self in Objective-C, the square brackets, the + and -, the nil, the YES/NO) but there are some things I really like, and messages and selectors are one of them. This is mostly because I think categories are cool, and informal protocols much more flexible than interfaces (and I like how you can implement the equivalent of an interface by making a formal protocol). Dividing the business of “calling a method” into its components makes sense to me.

On the other hand, some of the (mostly version 2.0) stuff does seem irritatingly inconsistent. For example, the dot notation. It wouldn’t be so bad if I wasn’t used to it in Java, but to have something so similar yet unexpectedly different is quite off-putting. Especially when getters, as you say, are named the same as ivars, but the setters aren’t and yet the only way to differentiate them in the dot notation is the context. Also, though properties are a neat way of simplifying the definition of getters and setters, it does seem to make it all a bit more opaque.

Incidentally, I learned getters and setters as accessors and mutators for some reason, only to find them collectively referred to as accessors later on. I guess this is one thing that everyone does differently…

I’ve got used to the square brackets now. I like the way there are class and instance methods (rather than the static business in Java) and that classes are objects. And I don’t find myself slower, partly because I never got to be that fast at Java and partly because I find Xcode to be quite helpful in a number of ways including helping me be a lazy coder! I also like interface builder generally, so overall I’m preferring it to Java so far.

Of course, I haven’t actually done anything but exercises with it yet, so the real test will be in the application.