Apple's resource programming guide (RPG) states "it is better to distribute components across multiple nib files."...
therefore,
i have an associate window nib (Nib 2) that has an nsobjectcontroller that needs to be linked (selection self) to a nsarraycontroller in the main document window nib (Nib 1).
i need to share a common instance (either the nsarraycontroller in nib 1 or nsobjectcontroller in nib2). I can add a custom object in Nib 1. and set the File's Owner to that type of custom object. however, each nib instantiates their own instance.
is there a method of setting which nib an object was instantiated, or declaring an external reference.
i also "Make the File’s Owner the single point-of-contact for anything outside of the nib file" (RPG). Which is a NSWindowController.
Thanks in advance.
You probably want to make the owner of NIB1 responsible for instantiating NIB2. This will allow it to be the owner of both NIBs. In the common case, it might look something like this:
// In the interface...
#property (nonatomic, readwrite, retain) NSArray* nib2TopLevelObjects;
// In the implementation...
- (void)awakeFromNib
{
NSNib* nib2 = [[[NSNib alloc] initWithNibNamed: #"NIB2" bundle: [NSBundle mainBundle]] autorelease];
NSArray* tlo = nil;
[nib2 instantiateWithOwner: self topLevelObjects: &tlo];
self.nib2TopLevelObjects = [tlo retain];
// Do other stuff...
}
- (void)dealloc
{
[_nib2TopLevelObjects release];
[super dealloc];
}
At the end of this, NIB2 will have been instantiated with NIB1's owner as it's owner as well, and NIB2 will have plugged its objects into the shared owner (be sure not to plug things into the same outlet from both NIBs.)
All that said, I'm not sure this is necessarily the right pattern to use here. If these windows are both views upon the same document, you should probably make an NSWindowController subclass for each window and override -[NSDocument makeWindowControllers] to instantiate them. (The NSWindowController will be the "File's Owner" for each NIB.) Having the document NIB's owner be the NSDocument subclass is a "short cut" for simple situations. Once you need multiple windows, NSWindowControllers are the way to go.
Each NSWindowController can get back to the document via -document and the NSDocument subclass can coordinate state between the different NSWindowControllers. This is a cleaner approach, and avoids all the shenanigans with clobbered IBOutlets, etc.
For your specific case, I could see having a property like sharedArrayController on the NSDocument subclass that gets the NSArrayController from NIB1 during -makeWindowControllers, and re-vends it. Then you can then access it from NIB2 by binding to File's Owner > document.sharedArrayController.selection.
Related
I've got plenty of experience with iOS, but Cocoa has me a bit confused. I read through several Apple docs on Cocoa but there are still details that I could not find anywhere. It seems the documentation was written before the NSDocument-based Xcode template was updated to use NSViewController, so I am not clear on how exactly I should organize my application. The template creates a storyboard with an NSWindow, NSViewController.
My understanding is that I should probably subclass NSWindowController or NSWindow to have a reference to my model object, and set that in makeWindowControllers(). But if I'd like to make use of the NSViewController instead of just putting everything in the window, I would also need to access my model there somehow too. I notice there is something called a representedObject in my view controller which seems like it's meant to hold some model object (to then be cast), but it's always nil. How does this get set?
I'm finding it hard to properly formulate this question, but I guess what I'm asking is:how do I properly use NSViewController in my document-based application?
PS: I understand that NSWindowController is generally meant to managing multiple windows that act on one document, so presumably if I only need one window then I don't need an NSWindowController. However, requirements might change and having using NSWindowController may be better in the long run, right?
I haven't dived into storyboards but here is how it works:
If your app has to support 10.9 and lower create custom of subclass NSWindowController
Put code like this into NSDocument subclass
- (void)makeWindowControllers
{
CustomWindowController *controller = [[CustomWindowController alloc] init];
[self addWindowController:controller];
}
If your app has multiple windows than add them here or somewhere else (loaded on demand) but do not forget to add it to array of document windowscontroller (addWindowController:)
If you create them but you don't want to show all the windows then override
- (void)showWindows
{
[controller showWindow:nil]
}
You can anytime access you model in your window controller
- (CustomDocument *)document
{
return [self document];
}
Use bindings in your window controller (windowcontroller subclass + document in the keypath which is a property of window controller)
[self.textView bind:#"editable"
toObject:self withKeyPath:#"document.readOnly"
options:#{NSValueTransformerNameBindingOption : NSNegateBooleanTransformerName}];
In contrast to iOS most of the views are on screen so you have to rely on patterns: Delegation, Notification, Events (responder chain) and of course MVC.
10.10 Yosemite Changes:
NSViewController starting from 10.10 is automatically added to responder chain (generally target of the action is unknown | NSApp sendAction:to:from:)
and all the delegates such as viewDidLoad... familiar from iOS are finally implemented. This means that I don't see big benefit of subclassing NSWindowCotroller anymore.
NSDocument subclass is mandatory and NSViewController is sufficient.
You can anytime access you data in your view controller
- (CustomDocument *)document
{
return (CustomDocument *)[[NSDocumentController sharedDocumentController] documentForWindow:[[self view] window]];
//doesn't work if you do template approach
//NSWindowController *controller = [[[self view] window] windowController];
//CustomDocument *document = [controller document];
}
If you do like this (conforming to KVC/KVO) you can do binding as written above.
Tips:
Correctly implement UNDO for your model objects in Document e.g. or shamefully call updateChangeCount:
[[self.undoManager prepareWithInvocationTarget:self] deleteRowsAtIndexes:insertedIndexes];
Do not put code related to views/windows into your Document
Split your app into multiple NSViewControllers e.g.
- (void)prepareForSegue:(NSStoryboardSegue *)segue sender:(id)sender {
if ([segue.identifier isEqualToString:AAPLListWindowControllerShowAddItemViewControllerSegueIdentifier]) {
AAPLListViewController *listViewController = (AAPLListViewController *)self.window.contentViewController;
AAPLAddItemViewController *addItemViewController = segue.destinationController;
addItemViewController.delegate = listViewController;
}
}
Previous code is called on windowcontroller with viewcontroller as delegate (again possible only after 10.10)
I always prefer to use multiple XIBs rather than one giant storyboard/XIB. Use following subclass of NSViewController and always inherit from it:
#import <Cocoa/Cocoa.h>
#interface MyViewController : NSViewController
#property(strong) IBOutlet NSView *viewToSubstitute;
#end
#import "MyViewController.h"
#interface MyViewController ()
#end
#implementation MyViewController
- (void)awakeFromNib
{
NSView *view = [self viewToSubstitute];
if (view) {
[self setViewToSubstitute:nil];
[[self view] setFrame:[view frame]];
[[self view] setAutoresizingMask:[view autoresizingMask]];
[[view superview] replaceSubview:view with:[self view]];
}
}
#end
Add a subclass of MyViewController to the project with XIB. Rename the XIB
Add NSViewController Object to the XIB and change its subclass name
Change the loading XIB name to name from step 1
Link view to substitute to the view you want to replace
Check example project Example Multi XIB project
Inspire yourself by shapeart or lister or TextEdit
And a real guide is to use Hopper and see how other apps are done.
PS: You can add your views/viewcontroller into responder chain manually.
PS2: If you are beginner don't over-architect. Be happy with the fact that your app works.
I'm relatively new to this myself but hopefully I can add a little insight.
You can use the view controllers much as you would in ios. You can set outlets and targets and such. For NSDocument-based apps you can use a view controller or the window controller but I think for most applications you'll end up using both with most of the logic being in the view controller. Put the logic wherever it makes the most sense. For example, if your nsdocument can have multiple window types then use the view controller for logic specific to each type and the window controller for logic that applies to all the types.
The representedObject property is primarily associated with Cocoa bindings. While I am beginning to become familiar with bindings I don't have enough background to go into detail here. But a search through the bindings programming guide might be helpful. In general bindings can take the place of a lot of data source code you would need to write on ios. When it works it's magical. When it doesn't work it's like debugging magic. It can be a challenge to see where things went wrong.
Let me add a simple copy-pastable sample for the short answer category;
In your NSDocument subclass, send self to the represented object of your view controller when you are called to makeWindowControllers:
- (void) makeWindowControllers
{
NSStoryboard* storyboard = [NSStoryboard storyboardWithName: #"My Story Board" bundle: nil];
NSWindowController* windowController = [storyboard instantiateControllerWithIdentifier: #"My Document Window Controller"];
MyViewController* myController = (id) windowController.contentViewController;
[self addWindowController: windowController];
myController.representedObject = self;
}
In you MyViewController subclass of NSViewController, overwrite setRepresentedObject to trap it's value, send it to super and then make a call to refresh your view:
- (void) setRepresentedObject: (id) representedObject
{
super.representedObject = representedObject;
[self myUpdateWindowUIFromContent];
}
Merci, bonsoir, you're done.
My app was converted from a non-document-based app to a document-based one. I did that by creating a subclass of NSDocument, called Document. I also created a Document.xib and set its "File's Owner" to Document.
Now in Document.xib, I can see there is a window outlet in its "File's Owner". I don't have a window outlet defined in Document. Where does it come from? I guess it is from the super class NSDocument, but I have no access to that variable in Document. What's up with this weird window outlet?
Have a look at the documentation for -[NSDocument setWindow:]
This method is invoked automatically during the loading of any nib for which this document is the file’s owner, if the file’s owner window outlet is connected in the nib. You should not invoke this method directly, and typically you would not override it either.
NSDocument doesn't deal with NSWindows directly, but it keeps a list of NSWindowControllers that you can access via the -[NSDocument windowControllers] method. My guess is that when setWindow: gets called, it wraps the window in a new NSWindowController and adds it to the list.
You should be able to access the window with something like this:
NSWindowController* controller = self.windowControllers.lastObject;
NSWindow* window = controller.window;
I just made a new project to test it, and this works:
- (void)windowControllerDidLoadNib:(NSWindowController *)aController {
[super windowControllerDidLoadNib:aController];
NSLog(#"%#", [self.windowControllers.lastObject window]);
}
Is it safe to do the following?
// in AppController.h
#interface AppController : NSObject
{
IBOutlet NSTextField *label;
}
#end
// in AppController.m
- (void)awakeFromNib
{
[label setIntValue:5];
}
Or is there a chance that label might not yet have been fully initialised when awakeFromNib is sent to the AppController instance?
Documentation says:
Important
Because the order in which objects are instantiated from an archive is not guaranteed, your initialization methods should not send messages to other objects in the hierarchy. Messages to other objects can be sent safely from within awakeFromNib—by which time it’s assured that all the objects are unarchived and initialized (though not necessarily awakened, of course).
In Fact, awakeFromNib is send to all objects the nib created and File's Owner , after creation of the objects and connecting outlets and actions is complete.
I'm not sure if it is safe.
But you should use viewDidLoad: for any view setup after the loading of the nib file.
I created a NSWindow xib file that I want to open on click of a button in another window.
Now, to control the behavior of the NSWindow, I dragged an object from Library in xib and changed it to subclass of NSWindowController (i.e. ListingWindowController) that I defined in XCode.
Similarly I also created a subclass of NSViewController (i.e. ListingViewController) to manage the NSView inside the NSWindow. To do this, I dragged NSViewController from Library in xib and changed its class to ListingViewController.
#class ListingViewController;
#interface ListingWindowController : NSWindowController {
IBOutlet ListingViewController *listingVC;
}
#property (nonatomic, retain) IBOutlet ListingViewController *listingVC;
#end
I connected window and listingVC of my window controller in IB.
Now to invoke this window on click of a button in my launch (first) window, I create the window controller using initWithWindowNibName like this..
- (IBAction) pushConnect:(id)sender {
NSLog(#"Connect pushed.");
if (wc == nil) {
wc = [[ListingWindowController alloc] initWithWindowNibName:#"ListingWindow" owner:self];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(closeWindow:) name:NSWindowWillCloseNotification object:nil];
[wc showWindow:sender];
}
}
The problem is that despite all the bindings done in IB for the view controllers of upcoming window/view, the window and listingVC comes out to be (null), (null) even after the new window has loaded (below code).
- (void)windowDidLoad {
[super windowDidLoad];
NSLog(#"windowDidLoad = %#, %#", self.window, self.listingVC);
}
Please help why the connections are not working. I'm banging my head against this problem for quite a while now.
PS: I'm coming from iOS programming background. So, I'm assuming the Mac's window/view controller behave similar to iOS UIViewControllers.
TIA..
Note that:
wc = [[ListingWindowController alloc] initWithWindowNibName:#"ListingWindow" owner:self];
means that self (it’s not clear what self is from your question) is the owner of ListingWindow.nib. This means that self is the one who keeps outlets to objects in that nib file, and self is responsible for releasing the top-level objects in the nib file. This also means that you’re creating an instance of ListingWindowController in your code and another instance inside your nib file since you’ve dragged an object of class ListingWindowController onto the nib file.
This is not how it’s supposed to be.
In the vast majority of cases, a window (view) controller loads a nib file and becomes its owner. It has a window (view) outlet that must be linked to a top-level window (view) in the nib file. Being the nib file’s owner, it must have been created before the nib file is loaded.
In order to achieve this for your window controller, you need to set the file’s owner class to ListingWindowController. You must not drag an object cube and instantiate the window controller inside the nib file. The window controller is the owner of the nib file, so it must exist before the nib file is loaded. You must also link the window outlet in file’s owner to the top-level window object in the nib file so that the window controller is aware of what window it should manage.
Having done that, use:
wc = [[ListingWindowController alloc] initWithWindowNibName:#"ListingWindow"];
instead of:
wc = [[ListingWindowController alloc] initWithWindowNibName:#"ListingWindow" owner:self];
since wc is supposed to be the owner of the nib file.
View controllers work similarly. They’re created before loading the nib file, are responsible for loading a nib file that contains a view as a top-level object, are that nib file’s owner, and have a view outlet that must be linked to that top-level view.
It’s not clear from your question whether you have a separate nib file for the view. If you don’t, then using a subclass of NSViewController is not needed at all — you could use a subclass of NSObject instead. If you insist on using NSViewController to manage a view that’s not loaded from a separate nib file, then you should override -loadView so that you get a reference to the view by some means other than loading it from a nib file, and sending it -setView: so that it is aware of the view it’s supposed to be managing.
Recommended reading: Nib Files in the Resource Programming Guide, NSWindowController class reference, NSViewController class reference.
I am new to document-based applications and hence I may have missed something fundamental. I have written a document based application which uses a subclassed NSWindowController for the interface and a subclassed NSDocument for the model. Per the documentation I initialise the windowController in makeWindowControllers and load its xib. In interface builder, the xib has my windowController subclass set as File's Owner. Among the views in the window, I have a subclass of NSOutlineView and the NSOutlineView datasource and delegate are also refenced in the nib and connected to the windowController via IBOutlets.
According to the documentation, I should be able to access the document from the OutlineView datasource via [windowController document]. However, referencing the windowController (via IBOutlet) from the OutlineView datasource gives me the document instead!
This has lead to some rather ugly code in the OutlineView datasoure (which is a subclass of NSObject in the windowController's xib) to get hold of the document, eg:
-(MyDocument *)myDocument {
MyDocument *theDocument = (MyDocument *)myWindowController;
return theDocument;
}
Where the IBOutlet in the header file references myWindowController as:
IBOutlet MyWindowController *myWindowController
In brief - why does an IBOutlet connected to the windowController get me the document directly instead in this situation? The above code works but seems as if it shouldn't.
Edit: clarification
Okay, I worked out the answer to this one - don't accidentally set the File's Owner of the xib to the NSDocument instead of the windowController in another part of your code and forget that you did it! This overrides the File's Owner that you previously set in the xib.