 |
|||||||||
|
|||||||||
|
|
So I was cruising along, clicking around in Interface Builder making a pretty rudimentary application tonight. I wasn't particularly concerned with how cool the app was or what it did - I was interested in the act of building the interface itself. What I was finding was that it took quite a few more keystrokes and actions to rig up a simple event handler in IB than it does in Visual Studio. At first, this frustrated me, but then I took a step back and tried to look at it objectively.
Let's take a simple example, which is actually the challenge from Chapter 4 of Aaron Hillegass' book. The goal is to have a text entry field, a button to click, and a read-only text label that displays the count of characters in the string when you push the button. So, if you enter "test", then click the button, the label's text changes to "test has 4 characters.". Pretty simple.
To do it in Visual Studio, I drop the UI elements onto the page, double-click the button. The event handler is automatically rigged up and inserted into the code-behind for the form. I would then add a line of code like this:
myLabel.Text = string.Format("{0} has {1} characters.",
textBox.Text, textBox.Text.Length);
To do the same thing in Interface Builder and Xcode, I would use the classes list in IB to create a subclass of NSObject called AppController, then I'd create an instance of it. Then, I'd create an outlet for the text input field, an outlet for the label (also a text field), and I'd create an action called countLetters: that has code that looks like this:
#import "AppController.h"
@implementation AppController
- (IBAction)countLetters:(id)sender
{
NSString *source = [textField stringValue];
NSString *formattedOutput =
[NSString stringWithFormat:@"%@ has %d letters",
source, [source length]];
[countLabel setStringValue:formattedOutput];
}
@end
At first glance, especially if you're used to Visual Studio, you're probably thinking that this seems like a fairly lengthy process to go through just to rig up a single event handler. Those of us who have been using Visual Studio since "way back in the day" might be included to think: Why can't I just double-click and code? Habitually, we tend to simply reach for a control on the GUI, double-click it, and start writing the event handler.
At this point, many of us developers begin to exhibit what I call "Double Click and Code Syndrome (DCACS)". Through convention, habit, and convenience we have lost sight of the pure intent and purpose of the Model-View-Controller pattern and we shun the 30 extra seconds required to rig things up in Cocoa because...well, it takes 30 more seconds.
In Cocoa, the controller is something that you actively choose to create. You can have multiple controllers for a single window or view if you like. And here's the important part: the controllers themselves are loosely coupled from the GUI itself. You can, in theory, re-use the controller among multiple applications provided the controller's purpose remains the same in each application.
The feeling I get from Visual Studio is that when you double-click on things in the GUI, you are dangling tightly coupled event handlers off of the view, when the code really should be in a designated controller. Surely with the right amount of patience, discipline, and good naming conventions you can make that environment "feel" more loosely coupled, re-usable, and controller-like.
What I'm wondering is: as I learn Cocoa and use Interface Builder and Xcode, how many more bad habits like DCACS am I going to have to unlearn in order to make coding on the Mac a more enjoyable, professional-quality experience?
I spent 4 years as a VB 6 developer. I now do Mac development. What you are
going to find is that doing things RIGHT in a microsoft environment is
harder than doing things RIGHT in the Cocoa/IB environment.
"You can, in theory, re-use the controller among multiple applications
provided the controller's purpose remains the same in each application."
Some neat direct comparsions are also possible if you try to design "XP
Style Controls - in Cocoa".
Think about what you have to do when you change the UI ?
GI - I couldn't agree more. The bad habits that being able to double-click
and immediately start coding generates are awful. As I've mentioned a few
times before, learning Cocoa is actually forcing me to unlearn quite a few
bad habits instilled by Visual Studio
Re: Harvey, "nobody does it" is simply wrong. Many of the interfaces Apple
uses (ie iTunes, or iPhoto which is Cocoa) use shared controllers with
multiple views, reusing them logically as needed. Cocoa even implements
most of the controller layer in a reusable fashion (see
bindings/NSController) exactly to help implement this kind of things!
"You can, in theory, re-use the controller among multiple applications
provided the controller's purpose remains the same in each application."
That's funny because I'm finding the EXACT opposite.