I have a plain blue cube object in IB called AppController. Here is the header file:
//AppController.h
#import <Cocoa/Cocoa.h>
#interface AppController : NSObject <NSCoding>
#property (weak) IBOutlet NSView *view;
#property (assign) int numberOfPresses;
- (IBAction)buttonPressed:(id)sender;
#end
As you can see it has an outlet to the view, a property called numberOfPresses, and and action tied to a button in IB.
Here is the implementation file
//AppController.m
#import "AppController.h"
#implementation AppController
-(void)awakeFromNib {
NSLog(#" number of presses = %d", _numberOfPresses);
}
- (IBAction)buttonPressed:(id)sender {
_numberOfPresses++;
NSLog(#" number of presses = %d", _numberOfPresses);
}
#pragma mark - Coding Protocol
-(void)encodeWithCoder:(NSCoder *)aCoder {
[aCoder encodeInt:_numberOfPresses forKey:#"numberOfPresses"];
}
-(id)initWithCoder:(NSCoder *)aDecoder {
self = [super init];
if (self) {
_numberOfPresses = [aDecoder decodeIntForKey:#"numberOfPresses"];
}
return self;
}
#end
As you can see, when the user presses on the button, the numberOfPresses is incremented. As I quit the app and fire it up again I would like
the numberOfPresses to be remembered.
The view outlet to stil be pointing to a valid view.
Now I always get 0 for numberOfPresses, and if I try to force the archiving using NSKeyedArchiver and NSKeyedUnarchiver from AppDelegate then I end up with view = null.
This problem is a general problem of archiving plain blue cube objects from IB. But I have not found an explanation of this on the Internet, although it should be a quite common problem. I must be missing or misunderstanding something.
Requirement #2 should be easy. If you do nothing, then the AppController should be loaded with its view created. In a sense it is "pre-archived" for you.
That means the real problem is how to restore the number of presses.
For something that simple, NSUserDefaults is a likely candidate. Update the defaults on a press and retrieve it during awakeFromNib.
Custom archiving and unarchiving is generally better for complete custom objects that are created dynamically, rather than ones loaded from IB.
(If it was a complicated network of objects you needed to restore, I'd be talking about CoreData instead.)
What I was after was a GENERAL solution that I could implement in ANY project and that ONLY uses NSCoding. (If anyone has a simpler solution, I would very much like to hear it). I ended up with a solution that works, by introducing two objects: a Hub, and a RootObject. The idea can be summarized in three points:
The idea is to free all objects that you want to archive from having any presence in the IB.
Introduce a Hub object which is responsible for all IB connections. The Hub is a blue cube in IB and has an outlet to AppDelegate. The AppDelegate has an outlet to the Hub.
Introduce a RootObject whose purpose is to propagate archiving to all objects that you want to archive. The RootObject is owned by the AppDelegate. The AppDelegate is responsible for initiating the archiving and unarchiving, and the RootObject is the mediator.
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.
The upcoming OSX 10.10 ("Yosemite") offers a new type of view, NSVisualEffectView, which supports through-the-window or within-the-window translucency. I'm mostly interested in through-the-window translucency, so I'm going to focus on that in this question, but it applies to within-the-window translucency as well.
Using through-the-window translucency in 10.10 is trivial. You just place an NSVisualEffectView somewhere in your view hierarchy and set it's blendingMode to NSVisualEffectBlendingModeBehindWindow. That's all it takes.
Under 10.10 you can define NSVisualEffectViews in IB, set their blending mode property, and you're off and running.
However, if you want to be backwards-compatible with earlier OSX versions, you can't do that. If you try to include an NSVisualEffectView in your XIB, you'll crash as soon as you try to load the XIB.
I want a "set it and forget it" solution that will offer translucency when run under 10.10 and simply degrade to an opaque view when run on earlier OS versions.
What I've done so far is to make the view in question a normal NSView in the XIB, and then add code (called by awakeFromNib) that checks for [NSVisualEffectView class] != nil, and when it's the class is defined, I create an instance of the NSVisualEffectView, move all my current view's subviews to the new view, and install it in place. This works, but it's custom code that I have to write every time I want a translucent view.
I'm thinking this might be possible using an NSProxy object. Here's what I'm thinking:
Define a custom subclass of NSView (let's call it MyTranslucentView). In all the init methods (initWithFrame and initWithCoder) I would throw away the newly created object and instead create a subclass of NSProxy that has a private instance variable (myActualView). At init time it would decide to create the myActualView object as an NSVisualEffectView if OS>=10.10, and a normal NSView under OS<10.10.
The proxy would forward ALL messages to it's myActualView.
This would be a fair amount of fussy, low-level code, but I think it should work.
Has anybody done something like this? If so, can you point me in the right direction or give me any pointers?
Apple is MUCH more open with the Beta agreement with Yosemite a than with previous Betas. I don't think I'm violating my Beta NDA by talking about this in general terms, but actual code using NSVisualEffectView would probably need to be shared under NDA...
There is a really simple, but somewhat hacky solution: Just dynamically create a class named NSVisualEffectView when your app starts. Then you can load nibs containing the class, with graceful fallback on OS X 10.9 and earlier.
Here's an extract of my app delegate to illustrate the idea:
AppDelegate.m
#import "AppDelegate.h"
#import <objc/runtime.h>
#implementation PGEApplicationDelegate
-(void)applicationWillFinishLaunching:(NSNotification *)notification {
if (![NSVisualEffectView class]) {
Class NSVisualEffectViewClass = objc_allocateClassPair([NSView class], "NSVisualEffectView", 0);
objc_registerClassPair(NSVisualEffectViewClass);
}
}
#end
You have to compile this against the OS X 10.10 SDK.
How does it work?
When your app runs on 10.9 and earlier, [NSVisualEffectView class] will be NULL. In that case, the following two lines create a subclass of NSView with no methods and no ivars, with the name NSVisualEffectView.
So when AppKit now unarchives a NSVisualEffectView from a nib file, it will use your newly created class. That subclass will behave identically to an NSView.
But why doesn't everything go up in flames?
When the view is unarchived from the nib file, it uses NSKeyedArchiver. The nice thing about it is that it simply ignores additional keys that correspond to properties / ivars of NSVisualEffectView.
Anything else I need to be careful about?
Before you access any properties of NSVisualEffectView in code (eg material), make sure that the class responds to the selector ([view respondsToSelector:#selector(setMaterial:)])
[[NSVisualEffectView alloc] initWithFrame:] still wont work because the class name is resolved at compile time. Either use [[NSClassFromString(#"NSVisualEffectView") alloc] initWithFrame:], or just allocate an NSView if [NSVisualEffectView class] is NULL.
I just use this category on my top-level view.
If NSVisualEffects view is available, then it inserts a vibrancy view at the back and everything just works.
The only thing to watch out for is that you have an extra subview, so if you're changing views around later, you'll have to take that into account.
#implementation NSView (HS)
-(instancetype)insertVibrancyViewBlendingMode:(NSVisualEffectBlendingMode)mode
{
Class vibrantClass=NSClassFromString(#"NSVisualEffectView");
if (vibrantClass)
{
NSVisualEffectView *vibrant=[[vibrantClass alloc] initWithFrame:self.bounds];
[vibrant setAutoresizingMask:NSViewWidthSizable|NSViewHeightSizable];
[vibrant setBlendingMode:mode];
[self addSubview:vibrant positioned:NSWindowBelow relativeTo:nil];
return vibrant;
}
return nil;
}
#end
I wound up with a variation of #Confused Vorlon's, but moving the child views to the visual effect view, like so:
#implementation NSView (Vibrancy)
- (instancetype) insertVibrancyView
{
Class vibrantClass = NSClassFromString( #"NSVisualEffectView" );
if( vibrantClass ) {
NSVisualEffectView* vibrant = [[vibrantClass alloc] initWithFrame:self.bounds];
[vibrant setAutoresizingMask:NSViewWidthSizable | NSViewHeightSizable];
NSArray* mySubviews = [self.subviews copy];
for( NSView* aView in mySubviews ) {
[aView removeFromSuperview];
[vibrant addSubview:aView];
}
[self addSubview:vibrant];
return vibrant;
}
return nil;
}
#end
I'm trying to get speech recognition working on a MacBook (OS 10.8.2) but I never get any callbacks on the delegate method. Using XCode 4.6 with ARC, here is my simple test code. I do get the "listening" output in the console. The "microphone" appears on screen and if I press the ESC key, then I can see my speech pattern in the display of the microphone, but still no delegate callbacks ever. There must be something basic missing but I haven't found it.
I've looked at numerous SO questions but none solve this. Some talk about calibration in the control panel, but I find nothing there for calibration (maybe that was a previous OS?).
Full project source available in github.
#import "RBListener.h"
#interface RBListener() <NSSpeechRecognizerDelegate>
#property (nonatomic, strong, readonly) NSSpeechRecognizer* recognizer;
#property (nonatomic, strong) NSArray* commands;
#end
#implementation RBListener
#synthesize recognizer = _recognizer;
- (id)init
{
self = [super init];
if (self) {
// initialize
_commands = #[#"hi", #"yes", #"no", #"hello", #"good", #"time"];
_recognizer = [[NSSpeechRecognizer alloc] init];
_recognizer.delegate = self;
_recognizer.commands = _commands;
_recognizer.listensInForegroundOnly = NO;
_recognizer.blocksOtherRecognizers = YES;
[_recognizer startListening];
DLog(#"listening");
}
return self;
}
#pragma mark -
#pragma mark NSSpeechRecognizerDelegate methods
- (void)speechRecognizer:(NSSpeechRecognizer*)sender didRecognizeCommand:(id)command
{
DLog(#"command: %#", command);
}
#end
It's likely your RBListener instance isn't sticking around (or is never even created), so right after everything's set up, there's no RBListener instance to receive the delegate messages.
The easiest thing to do is create an outlet in your XIB and connect it to an RBListener instance. That is, drag a basic "NSObject" (plain cube) into your xib from the library and change its class to "RBListener". This instance can then be referenced via your outlet (once you connect it in IB) AND should stick around in memory.
If you're alloc/initing your RBListener instance programmatically, make sure you're storing it somewhere (like as an instance variable on some other object that sticks around - your app delegate or your NSDocument subclass - whichever is appropriate to your design). If you don't stash it into a property or make it a singleton (another possible approach), ARC will kill it before you get a chance to use it since you did nothing to hold onto it.
I hope this helps.
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 would like to figure out how to perform drag and drop from strings in a table view onto a collection view. I know there are delegate methods for collectionView drag and drop but can't find any examples of how to implement them. I have my collection view set up, it seems to be working correctly but don't know how to finish.
Any help is appreciated.
Update: The collection view setup I am working with has 3 NSTextFields and 2 check boxes for each collection item. There is also a tableView in the same view. The table view is passed an a MutableArray of strings. I want to be able to drag string values from the table view rows into the appropriate textFields in the collection view item.
This is different from the typical way drag and drop is used for collection views.
I am going to answer my own question because I spent quite a bit of time today trying to figure this out, Many people struggle with this procedure and mostly because I feel bad I keep asking the Stack community all these collection view questions all week:
I discovered the default behavior of the NSTextField actually allows a drop if it is in focus. The problem is that I need the appropriate NSTextField to auto focus on mouse enetered event. So as things turned out, I did not even need the NSCollectionView drag and drop delegates. I needed the NSTableView drag delegates and I needed to subclass the NSTextField and implement mouse event (drop) delegates in it.
so my class for the original collectionViewItem look like this:
//someClass.h
#interface SomeClass : NSObject{
IBOutlet NSTextField *field1_;
IBOutlet NSTextField *field2_;
IBOutlet NSTextField *field3_;
IBOutlet NSButton *chkBox1_;
IBOutlet NSButton *chkBox2_;
}
#porperty(readwrite, copy) NSTextField *filed1_;
properties are made for all 5 outlets for binding purposes. If you follow the tutorial on the Mac OSX Dev Library ; Collection View Programming Guide, it walks you through the process of setting up a collection View but it uses bindings.
So now the key is to set up a textField sub class
//MyNSTextField.h
#import
#interface MyNSTextField : NSTextField{
//mouse positioning
unsigned long last_;
}
//MyNSTextField.m
#import "MtTextField.h"
#implementation
-(void)dealloc{
[super dealloc];
}
-(void)awakeFromNib{
//register for dragged types
//any other nib stuff
}
//three required mouse events
-(unsigned long)draggingEntered:(id<NSDraggingInfo>)sender{
//this forces the textfield to focus before drop
[self.window makeFirstResponder: self];
NSPasebord *pBoard;
self->last_ = DragOperationNone;
pBoard = [sender draggingPastboard];
return self->last_;
}
-(unsigned long)draggingUpdated:(id<NSDraggingInfo>)sender{
return self->last_;
}
-(void)draggingExited:sender{
if([sender draggingSource] != self){
self->last = NSDragOperationNone;
}
}
}// end class
now just go back to the original class and change the name of your textField outlets from NSTextField to MyNSTextField and in the collection view, select each textfield and assign it the new class name in the inspector and as long as you had your tableview drag delegates set up, or if your are dragging from some other source, make sure you have the appropriate dragging source delegates set and it should work.