How exactly is NSPrintInfo's sharedPrintInfo shared?

Question

Apple's documentation for NSPrintInfo states in part:

A shared NSPrintInfo object is automatically created for an application and is used by default for all printing jobs for that application.

The method sharedPrintInfo returns the shared NSPrintInfo. What's not explicitly stated is if you alter that object (e.g., by using setOrientation), do said alterations "stick" with the shared object? I.e., is the object you get back a singleton or a fresh copy of the shared object?

One reason I ask is because I've seen in some of Apple's sample code where they explicitly call setSharedPrintInfo at the end of a print job. Why do they do that if the shared object is a singleton?

Update

It seems I have to be clearer in my question. From Apple's documentation, there exists an instance of NSPrintInfo that is the "shared" one. This "shared" instance is used by default when no NSPrintInfo object is used explicitly in method calls. The method sharedPrintInfo returns a pointer to this "shared" instance.

What's not clear is whether sharedPrintInfo clones the "shared" instance and returns a pointer to that, or simply returns a pointer to the existing instance.

If cloned, then any call such as one to setOrientation will affect the clone only. If I wanted to alter the orientation of the "shared" instance also, I would have to call setSharedPrintInfo supplying the altered clone as an argument.

If not cloned, then it's not clear why Apple's sample code explicitly calls setSharedPrintInfo because all method calls altering the state of the NSPrintInfoObject returned by sharedPrintInfo already affected the "shared" instance.

Answer 1

It's not a singleton. There's a shared NSPrintInfo object, because most apps only need one. You can also create additional NSPrintInfo instances if that's appropriate to your situation.

Answer 2

What's not explicitly stated is if you alter that object (e.g., by using setOrientation), do said alterations "stick" with the shared object? I.e., is the object you get back a singleton or a fresh copy of the shared object?

Setters ordinarily return void; they don't return the object whose property you set. NSPrintInfo's setOrientation: method is one example.

Methods that return a copy of the receiver with the change applied say so explicitly in their name—for example, stringByAppendingString: (returns a modified copy), as opposed to appendString: (modifies the receiver).

So NSPrintInfo's setters only affect the object you send those messages to. If you send setOrientation: to the shared print info, you modify that object; you aren't creating a new print info.

OK, now for your actual question.

If you look at NSDocument, you'll see that each document can have its own print info. When the user enters Page Setup, they do so in a sheet on the document window, and their changes only affect that document—which is only possible by giving each document its own print info. If your app isn't document-based, it's probably a single-window app, and one print info for the whole process will do just fine.

The documentation for NSDocument calls out one specific case: You can override its printInfo method in your NSDocument subclass to always use the shared print info object. I can't imagine why you would do that, but in that case, the shared print info object is literally shared between all your open documents.

Answer 3

I don't know the answer to your question, but here's a simple test to find out: call sharedPrintInfo twice and compare the pointers. If they're the same, then no, you get the same NSPrintInfo object back each time. If they're different, then you get a different object back each time. You could do this in the debugger and have your answer in sixty seconds.

Answer 4

What's not clear is whether sharedPrintInfo clones the "shared" instance and returns a pointer to that, or simply returns a pointer to the existing instance.

In Cocoa, a sharedFoo method returns the shared foo object. It doesn't make a copy of it—that would defeat its purpose, which is to access the shared object.

This rule is also true of defaultFoo methods (e.g., [NSFileManager defaultManager]). Don't ask me why they call some of these methods defaultFoo and others sharedFoo. ☺

If you ever do want your own copy, many classes will let you make one; NSPrintInfo is one example that explicitly does allow this. Other classes (the shared panels in particular, such as NSColorPanel) exist in one and only one instance.

Answer 5

I haven't tried this, so feel free to down-vote me if I'm dead wrong.

The NSPrintInfo documentation states the following, which seems pretty clear:

A shared NSPrintInfo object is automatically created for an application and is used by default for all printing jobs for that application.

You can also initialize an instance of this class using the initWithDictionary: method. You can use this dictionary to store custom information associated with a print job.

This would indicate that you can either use the shared object OR create your own.

Now to the second part of your question, why do the Apple examples call setSharedPrintInfo: ?

If you create your own using initWithDictionary: you CAN then store it to be the new shared one. But you don't have to.

source: Mac Dev Center, NSPrintInfo Class Reference