On Sep 5, 2012, at 11:53 AM, Seth Willits <sli...@araelium.com> wrote:
> In a complex window where there a multiple tabbed views like you have, think
> of the window controller as doing nothing more than managing the view
> controllers for each of the tabs, not the actual views in each tab. If your
> window controller is getting monolithic, it's time for a refactor.
Amen to that: You can really start to encapsulate portions of your view well
this way, and the way they interact with your model as well.
> There's a view controller responsible for doing nothing more than managing
> the table view displaying the query results table, and basically has this
> interface:
>
> @interface ResultListViewController : NSViewController {
> NSTableView * resultListTableView;
> NSArrayController * resultListArrayController;
> }
>
> @property (readwrite, retain) NSArray * results;
>
> @end
>
> The view controller is the delegate and data source for the table view and
> manages a bunch of little things related to the table.
To go into a little more detail, I’d write the above like this, using Xcode 4.4
or later:
In CMHResultListViewController.h:
#import “CMHViewController.h”
@interface CMHResultListViewController : CMHViewController
@property (readwrite, copy) NSArray *results;
- (id)init; // designated initializer
@end
In CMHResultListViewController.m:
#import “CMHResultListViewController.h”
// Class extension for UI, it's not part of this class’s API.
@interface CMHResultListViewController () <NSTableViewDelegate,
NSTableViewDataSource>
@property (readwrite, assign) IBOutlet NSTableView *resultListTableView;
@property (readwrite, assign) IBOutlet NSArrayController
*resultListArrayController;
@end
@implementation CMHResultListViewController {
@private
// …additional ivars that may be needed…
}
// …rest of implementation…
@end
With this, I would:
- Use a “base subclass” of NSViewController for my project, in which I can
implement project-wide functionality. (For example, I could make -init the
designated initializer for such controllers, and have them derive their nib
name from their class name.)
- Separate things needed by Interface Builder (IBOutlet, delegate & data source
protocol declarations) from the API of the class as used by the rest of the
class.
- Avoid declaring ivars that I don’t need to any more, since they’ll be
auto-synthesized for me.
- Avoid declaring ivars in the interface to the class, giving clients of it
details that they should actively avoid caring about.
- Make Interface Builder go through accessors (by putting the IBOutlet marker
on the property declarations) rather than straight to ivars, allowing a little
more flexibility.
Of course, this all assumes using the latest tools and compiler, and no
requirement to remain compatible with 32-bit Intel (the old ObjC runtime). If
it had to remain compatible, though, about the only thing I’d have to do
differently is put ivar declarations in the main @interface in the header file.
-- Chris
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
