Re: Questions-fest
Re: Questions-fest
- Subject: Re: Questions-fest
- From: Scott Thompson <email@hidden>
- Date: Thu, 30 Jun 2005 08:46:53 -0500
On Jun 30, 2005, at 8:22 AM, Mark Papadakis wrote:
Greetings,
I recently ( 2 weeks ago ) switched to Mac from Windows. My only
regret is that it took me so long to 'do the right thing'. I have
been browsing Apple's documentation, searching for tutorials on the
Net ( very, very few out there ) and playing around with XCode 2.1,
trying to get comfortable with the development environment.
I got Aaron's Hillegrass's book on Cocoa programming [Cocoa:
Programming for OS X, Addison Wesley], but it didn't really explain
much to me. So, here is a list of question for anyone who would be
kind enough to help me:
o I am trying to figure out exactly how events are handled in a
Cocoa application. If I got it right, applications from Windows
Server, and other sources, end up in the application's events
queue. The NSApplication object picks up events from that queue in
its event loop and then.. :
o Does it dispatch them directly to the NSview responsible for
that event?
If it's a mouse event then it does. Other kinds of events may not go
directly to the view. As a general rule, events are routed to the
"person" most likely to be able to respond to them properly.
o Does it dispatch them to the firstResponder of the NSWindow,
who's NSView object has to handle the event?
Depends on the event and how it's targeted. Key events are sent to
the object with the key focus, or the first responder if there isn't
one. Command events usually go to the first responder.
http://developer.apple.com/documentation/Cocoa/Conceptual/
BasicEventHandling/Concepts/AboutRespChain.html
o Does it dispatch them to NSWindow, which dispatches them to
the NSView ?
Typically, a view will get first crack at an event and propagate it
up the responder chain to the window as necessary.
Also, when an NSView doesn't handle an event, it bounces it back to
its super-view ( up to NSwindow itself ). How does the super view
know that the event originated from one of its sub-views, and not
really intended for that view, originally?
As a general rule, it doesn't. Does it matter?
o Is it advised to use a separate NIB file for each window?
That's more a matter of taste really. I often group related windows
together into one nib (if a window has a related sheet for example).
When you load a nib, however, you load all of the assets inside of it
along with it. Usually it's best to put a fine granularity on it so
you're not loading a bunch of stuff you're not ready to use.
o Is it advised to use a different controller object for each window?
Usually that makes the most sense. The controller ties into the
specific controls on that particular window after all.
o How does networking work ? In Win32, for example, I/O events were
dispatched to your window as normal events (read/write/error
availability). Do you have to use select()/read()/write() and other
'low-level' POSIX API calls?
No, there layers built on top of the POSIX APIs that you can use.
Core Foundation includes networking classes:
Start at the Cocoa documentation site:
<http://developer.apple.com/documentation/Cocoa/index.html>
and click on the heading for "Networking"
o Are document-based applications the norm? Should my apps adhere
to this concept?
It depends on your application. Many of the popular applications
from Apple are not document based. I.e. iTunes, iCal, Address Book,
Mail, etc...
Other applications use documents because that makes sense for their
design.
What you should NOT do is try and use an "MDI" window. Read the
hints here:
<http://developer.apple.com/ue/switch/windows.html>
Enjoy!
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden