Re: Minimal document-based app
Re: Minimal document-based app
- Subject: Re: Minimal document-based app
- From: Chris Hanson <email@hidden>
- Date: Wed, 02 May 2012 12:51:18 -0700
On May 2, 2012, at 6:19 AM, ecir hana <email@hidden> wrote:
> - I saw that Xcode named the Info.plist differently (it prepends my project
> name to it) - is it ok just to call it Info.plist? Is there any convention?
Xcode is actually prepending the target name, not the project name: A project can have multiple targets, creating a new project really creates a new empty project and then adds a target of the desired type with the same name.
Using a «TargetName»-Info.plist as the name also helps to emphasize that it’s a source file, not something copied wholesale into the output. For example, build settings using ${SETTING_NAME} syntax in «TargetName»-Info.plist are expanded, for example
<key>CFBundleIdentifier</key>
<string>com.example.${PRODUCT_NAME:rfc1034identifier}</string>
is used (assuming you specified a bundle identifier prefix of com.example) instead of hard-coding the app name into the bundle identifier.
> - I don't want to put the window in init, where else should I put it? Does
> NSDocument have an equivalent of applicationDidFinishLaunching, i.e. when
> the document is created is there any callback fired?
This is a case where I think trying to do everything “by hand” may be inducing some confusion and is definitely causing you to do more work than you probably need to.
The method -[NSDocumentController newDocument:] is what creates and presents a new untitled document; its documentation indicates what it sends to do so, and the documentation for those methods do the same in turn. In the end -[NSDocument makeWindowControllers] and -[NSDocument showWindows] are used to present the document’s human interface.
As you check out the documentation, you’ll see that by default, -[NSDocument makeWindowControllers] expects -[NSDocument windowNibName] to return the name of a nib file to use for the document’s human interface. In a lot of cases you’ll want a separate NSWindowController subclass, but even in those cases you’ll want it to use a nib (by initializing it with -[NSWindowController initWithWindowNibName:]) rather than a programmatically-wired-up window.
In essence, don’t make more work for yourself than you need to. What Interface Builder does for you is basically this:
Class1 *object1 = [[Class1 alloc] init];
Class2 *object2 = [[Class2 alloc] init];
Class3 *object3 = [[Class3 alloc] init];
owner.outlet1 = object1;
owner.outlet2 = object2;
owner.outlet3 = object3;
object1.property1 = owner;
object1.property2 = object2;
object2.property1 = object1;
object2.property2 = object3;
object2.target = owner;
object2.action = @selector(anAction:);
object3.target = firstResponder;
object3.action = @selector(anotherAction:);
[owner awakeFromNib];
[object1 awakeFromNib];
[object2 awakeFromNib];
[object3 awakeFromNib];
and so on. (Interface Builder actually uses archiving so it’ll use -initWithCoder: not -init, but the gist is clear.)
It really won’t teach you much about Cocoa to write dozens of lines of code like this by hand — plus you’ll wind up having to do a lot of extra work to get everything to look like it does when you drag it (pre-configured) out of the library in Interface Builder.
This is why people in the Cocoa community have the reaction we do when developers new to Cocoa ask how to put together interfaces without using Interface Builder, and why “don’t tell me not to, just tell me how” doesn’t generally get a good reception.
-- Chris
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden