macOS Substituting UI Classes with Custom ones

[Soulstorm]

I want this method to be applied in an iOS app, but since I think this applies to cocoa, I may as well ask here.

I want to make a custom view controller, and add some variables and methods. However, I want the same variables and methods to be applied into NSTableViewControllers, too. So I need a way to tell Cocoa to load my custom view controller instead of the normal one. and derive NSTableViewController from my custom view controller, too.

How can I do this in Cocoa?

 

[chown33]

How can I do this in Cocoa?

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.

 

[Soulstorm]

tell us what you want to accomplish, rather than how you want to accomplish it.

Actually, I want to create a networking-aware view controller, than will have some network-ready functions such as asynchronous get from server, and analysis of the data. I could just subclass NSViewController, but that would mean that I should also subclass NSTableViewController and write similar if not the same code for it, too.

However, that doesn't appear as the best solution for this problem.

 

[chown33]

Actually, I want to create a networking-aware view controller, than will have some network-ready functions such as asynchronous get from server, and analysis of the data. I could just subclass NSViewController, but that would mean that I should also subclass NSTableViewController and write similar if not the same code for it, too.

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.