macOS "Cocoa Programming For Mac OS X" Chapter 14 Challenge

[JGoose]

Could someone please help me out with this? I'm not sure what Hillegass means he says the program "gives up its active status."

 

[ChOas]

Could someone please help me out with this? I'm not sure what Hillegass means he says the program "gives up its active status."

I think it means your app lost focus, as in you switched to another application.

 

[JGoose]

I entered this into MyDocument.m but it doesn't work. What's wrong?

- (void) applicationDidResignActive: (NSNotification *) aNotification
{
	NSBeep();
	NSLog(@"Notification applicationDidResignActive:");
}

 

[chown33]

I entered this into MyDocument.m but it doesn't work. What's wrong?

Is your instance of MyDocument registered as the application delegate? If not, then you need to read the reference docs that discuss applicationDidResignActive: and learn how to add your delegate object.

You could try googling applicationDidResignActive.

 

[mdeh]

I entered this into MyDocument.m but it doesn't work. What's wrong?

- (void) applicationDidResignActive: (NSNotification *) aNotification
{
	NSBeep();
	NSLog(@"Notification applicationDidResignActive:");
}

As Chown noted above, it's an exercise to make sure you understand Hillegass, not always the easiest thing to do.

1) Make sure you add the correct (extra!) code when you have registered as an observer. ( Go back an look at page 213, in the init.)
Clue: need to add another addObserver:selector:name: object

Then it should work.

 

[JGoose]

Actually I have AppContrller set as the delegate so I just moved the applicationDidResignActive: to the AppController class and it worked.

But that produces another question. I put

- (void) windowDidResize: (NSNotification *) aNotification
{
	NSLog(@"Window did resize");
}

in MyDocument and it worked just fine. Why would this work there, while applicationDidResignActive: does not. And neither does windowDidResize: work in AppController.

 

[mdeh]

Why would this work there, while applicationDidResignActive: does not. And neither does windowDidResize: work in AppController.

If my understanding of this is correct, it is because AppController is **NOT** a delegate in the true sense of the word. The delegate is the connection made in IB. AppController is simply adding methods to observe during the init. I **think** you have to add each notification you wish to observe, in this case.
But, I am sure others will chime in if this is incorrect.

 

[JGoose]

But both applicationDidResignActive: and windowDidResize: are Notifications, right? So shouldn't they both only work in a delegate (that is if you don't use addObserver: selector: name: object: ), which in this case is AppController, and not MyDocument.

So my question is what is the difference between applicationDidResignActive: and windowDidResize: that they behave contrary to what I just said?

 

[chown33]

If I'm reading what you wrote correctly, you seem to think there's only one delegate in the entire app. This is incorrect. Delegation is a pattern: it identifies a relationship between two objects. That pattern is used in many different classes, to accomplish many different things.

The relationship between NSApp and the application delegate is one use of delegation. Certain notifications are observed by NSApp, and then translated by it into method calls to its delegate.

A completely different relationship is defined by the delegation of MyDocument and the window-related notifications, which it observes and translates into method calls to its delegate.

Suppose you're a CEO. You have a secretary. You know other CEOs who also have secretaries. If you tell your secretary to arrange a flight to Paris, none of the other secretaries get that order. Only your secretary is your delegate. If some other CEO arranges a cruise to the Bahamas, there's no confusion because each secretary is only taking orders from one director.


By the way, there are a lot of other Notifications that you don't know about yet, and they're being sent and observed as things happen. You may liken them to other messages sent to your secretary regarding things other than travel. Don't get too tied up in the analogy, though, because all analogies eventually break down.


In general, read this:

http://developer.apple.com/mac/libr.../CocoaDesignPatterns/CocoaDesignPatterns.html

On delegation, read these:
http://en.wikipedia.org/wiki/Delegation_pattern

http://developer.apple.com/mac/libr....html#//apple_ref/doc/uid/TP40002974-CH6-SW19

 

[JGoose]

No I didn't think that there is only one delegate in the app, but since you said that I decided it would probably be good to check if I had forgotten about an delegates I had set (ya, I know, should have thought to do that in the first place). And yes, the window is set as a delegate of the File's Owner in MyDocument.Xib.

So now it makes sense to me, thank you.

 

[mdeh]

If I'm reading what you wrote correctly, you seem to think there's only one delegate in the entire app. This is incorrect. Delegation is a pattern: it identifies a relationship between two objects. That pattern is used in many different classes, to accomplish many different things.

Hi Chown,
Well...maybe my understanding is not full yet. But, as i understand it, a single object can only have one delegate. So, if you set ObjectB as a delegate of ObjectA ( in IB), and *then* you wish to make ObjectC respond to certain notifications of ObjectA, you cannot make ObjectC a delegate of ObjectA as well, but you **can** register ObjectC with the notificationCenter to receive notifications for those changes you are interested in?? If this is not correct, and it may well be, then I would like to hear your input, as this seems to be the case as described by the OP.

Part of the confusion here is that Hillegass gives a really obfuscated explanation of delegation and notifications on page 213. Here is what he says.

If a standard Cocoa object has a delegate and posts notifications, it is automatically registered as an observer for the methods the object implements. If you are implementing such a delegate, how would you know what to call the method.

I assume that both *it* and *the object* refer to the delegate.

The problem is that prior to this sentence, he was talking about adding observers, so one does not assume he has suddenly changed track. If one looks at the book's site, quite a few are confused by this, ( maybe even including me ) So, the challenge would seem to indicate that all one needs to do is simply implement the method, and it should work. I have not done this exercise in a while, but the OP is correct in that the AppController was indeed made a delegate of "file's owner" which in this case was NSApplication. So, going by the logic of the previous discussion, it would seem to indicate that simply implementing the methods *should* be the only things needed. Interested in your input, before I go back and redo the exercise.

 

[mdeh]

But both applicationDidResignActive: and windowDidResize: are Notifications, right? So shouldn't they both only work in a delegate (that is if you don't use addObserver: selector: name: object: ), which in this case is AppController, and not MyDocument.

So my question is what is the difference between applicationDidResignActive: and windowDidResize: that they behave contrary to what I just said?

I went back and redid these exercises...it's a little easier the second time round. To answer your specific questions.

AppController was made a delegate of NSApp and thus all notifications sent by NSApplication will **ONLY** be responded to by methods implemented in AppController. Hence, NSBeep() will only work if it is in the AppController...as you discovered. windowDidResize is a notification of NSWindow, and if you look where the delegate of the Window is, ( in IB) you will see it is File's owner, which you already know is "MyDocument". So, resizing will only be responded to by methods in MYDocument, and not in AppController.
Hope that helps.