FROM : Chris Hanson
DATE : Fri Jan 04 04:11:12 2008
On Jan 3, 2008, at 11:03 AM, Ben wrote:
> Most of these views are in separate nib files and their file's owner
> is a similarly named class (for example GroupView.nib has
> GroupViewManager.h/m).
Bill already addressed your GC concerns, but I thought this would be a
good example of the use of another new Leopard Cocoa feature,
NSViewController. The point of an NSViewController is to act as the
owner of an "independent" view hierarchy, just like you're doing with
your ViewManager classes.
NSViewController Class Reference
<http://developer.apple.com/documentation/Cocoa/Reference/NSViewController_Class/Introduction/Introduction.html
>
What I do is create an application-specific base class that derives
from NSViewController (call it MyAppViewController) that implements an
-init method like this:
- (id)init {
return [super initWithNibName:[self nibNameForClassName]
bundle:[NSBundle bundleForClass:[self
class]]];
}
I also implement a -nibNameForClassName method that gets the name of
the current class and lops off "Controller" (and possibly my custom
prefix, too) so that I don't litter my code with nib names; instead,
they're inherent in the class name.
One other thing I find it useful to do when subclassing
NSViewController is override -loadView to implement pre/post-load
hooks like NSWindowController has:
- (void)viewWillLoad {
// Here for subclasses to override.
}
- (void)viewDidLoad {
// Here for subclasses to override.
}
- (void)loadView {
[self viewWillLoad];
[super loadView];
[self viewDidLoad];
}
These hooks have come in handy occasionally. There's also -
awakeFromNib, of course, but I generally try to only implement things-
I-wish-I-could-do-in-IB in that method (e.g. setting the double action
of a table view), and perform more controller-level operations (such
as telling a data source to fetch model objects) in a -
{window,view}DidLoad method.
-- Chris
DATE : Fri Jan 04 04:11:12 2008
On Jan 3, 2008, at 11:03 AM, Ben wrote:
> Most of these views are in separate nib files and their file's owner
> is a similarly named class (for example GroupView.nib has
> GroupViewManager.h/m).
Bill already addressed your GC concerns, but I thought this would be a
good example of the use of another new Leopard Cocoa feature,
NSViewController. The point of an NSViewController is to act as the
owner of an "independent" view hierarchy, just like you're doing with
your ViewManager classes.
NSViewController Class Reference
<http://developer.apple.com/documentation/Cocoa/Reference/NSViewController_Class/Introduction/Introduction.html
>
What I do is create an application-specific base class that derives
from NSViewController (call it MyAppViewController) that implements an
-init method like this:
- (id)init {
return [super initWithNibName:[self nibNameForClassName]
bundle:[NSBundle bundleForClass:[self
class]]];
}
I also implement a -nibNameForClassName method that gets the name of
the current class and lops off "Controller" (and possibly my custom
prefix, too) so that I don't litter my code with nib names; instead,
they're inherent in the class name.
One other thing I find it useful to do when subclassing
NSViewController is override -loadView to implement pre/post-load
hooks like NSWindowController has:
- (void)viewWillLoad {
// Here for subclasses to override.
}
- (void)viewDidLoad {
// Here for subclasses to override.
}
- (void)loadView {
[self viewWillLoad];
[super loadView];
[self viewDidLoad];
}
These hooks have come in handy occasionally. There's also -
awakeFromNib, of course, but I generally try to only implement things-
I-wish-I-could-do-in-IB in that method (e.g. setting the double action
of a table view), and perform more controller-level operations (such
as telling a data source to fetch model objects) in a -
{window,view}DidLoad method.
-- Chris
| Related mails | Author | Date |
|---|---|---|
| Ben | Jan 3, 20:03 | |
| Bill Bumgarner | Jan 3, 22:30 | |
| Chris Hanson | Jan 4, 04:11 |






Cocoa mail archive

