NSApplication allows you to set a delegate for your application. If the user drags a file onto your dock icon, NSApplication will call the method
- (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename
of your delegate object, in case it implements any such method. In case the content is not really a file (e.g. if the user just selects text in an application and drags it onto your dock icon), the delegate method
- (BOOL)applicationOpenUntitledFile:(NSApplication *)theApplication
is called.
See NSApplication class reference
Basically you can just create any object of any kind (e.g. a simple one that just inherits of NSObject), define the two methods of above within the object and then anywhere in your start up code of the app you do
whatever = [[YourObject alloc] init];
[[NSApplication sharedApplication] setDelegate:whatever];
And that's it. As soon as a file or some other content is dropped onto the dock icon, the appropriate method is called and must handle that request. BTW the same methods are called if your application associates with a file type (e.g. .myFileType) and the user double clicks a file with that extension in the Finder.
What really happens behind the scenes is that Launch Services sends your
application an "open documents" ('odoc') Apple Event. NSApplication by default registers a handle for this event and forwards the request by calling the appropriate delegate method. You can also directly listen to this Apple Event I guess, but why would you? Dealing with Apple Events directly is awkward. When your application is not Cocoa, but Carbon (plain-C), you may have to directly process the Apple Event (I'm not familiar with Carbon), but in Cocoa Apple already catches the most important Apple Events for you and converts them into delegate calls or notifications your application can listen to.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…