Substituting UI Classes with Custom ones

Short answer: You can't.

Long answer: You can't do it as described.

You can't add instance variables to any existing class. You can add methods to an existing class, which is what categories are for. Look up categories in the Objective-C Programming Language Guide.

I'm not sure if you can add properties to an existing class. You can certainly add the getter and setter methods, since those fall under the same rules as categories and class extensions. I'm just not sure if you can use the @property syntax, or @synthesize. You'll have to experiment.

Associative references can simulate instance variables being added to an existing class. There's a chapter on it in the language guide linked above.


There may be other ways to accomplish the same goal, if you explained what that goal is. In other words, tell us what you want to accomplish, rather than how you want to accomplish it.

Oh, and you tell Interface Builder to use your custom view controller class in the normal way: by adding a class and telling IB to use it.

 

I'm not sure I understand what network-ready functions would be appropriate for a view controller. A controller mediates between Model and View. To me, that suggests any network-ready functions should be in either the Model, because the Model is network-aware, or the View, because the View is network-aware. But I'm not sure what it would mean for a View to be network-aware, so that just leaves the Model.

If there's an async get from server or analysis of data, that seems to me like it all belongs in the Model. The Controller tells the Model when to do something, or asks it for what to present in the View, but I don't see the Controller needing to know how the Model does its thing. Being network-ready implies a how (the how being "over the network", and to me, all how's involving data are the responsibility of the Model.

Maybe your controller class is also acting more or less like a Model. That happens, especially if the data in the Model is relatively simple. But if you're considering a solution that involves retrofitting methods and variables to multiple predefined NSXyzController classes, then I think that's a clue that it's time to factor out the Model into a separate class or classes. It may also be a clue to review the MVC documentation.

The touchstone I use to decide whether something should be in the Model or the Controller is "Could I write an ncurses version of this program, and reuse the Model classes without change?" If there is any data-handling logic in a Controller class, then the answer will be "No", because I'd need to rewrite or refactor the functionality of that Controller to make the program work in ncurses. However, if I can replace the Controller(s) with new classes that handle ncurses-style interaction, then I know the Model has been properly factored out from the Controller. Ncurses knows nothing about nibs or NSViews. It's a classical terminal-handling library.

To further check my factoring of the Model, I ask myself whether I can write a version of the program using only command-line options as inputs. Again, that takes a completely different kind of Controller (and "View"), but if the Model can be used unchanged, then it's usually a good factoring.

Finally, I'm not aware of a NSTableViewController class on Mac OS X. There's a UITableViewController, but it only exists on iOS. So maybe your question is really better suited for the iOS Developer forum. If so, please say that, so this thread can be reported to the mods for moving to that forum.

And frankly, I'd suggest the same thing when targeting iOS. If you're considering adding methods and ivars to a predefined class, you should probably revise the relationship between the Controller and Model.