Re: Minimal document-based app
Re: Minimal document-based app
- Subject: Re: Minimal document-based app
- From: colo0logo <email@hidden>
- Date: Thu, 03 May 2012 11:06:28 -0400
I feel that there should be a long blog +video post that new devs
should be pointed to everytime this question(view/bad choice) crops up
that keeps all of the details of the many emails points that could be
like an Apple best of doc.
I know for sure that I have gone that route as well and still need to
get back to IB when I try again at deving.
Nick
On Wed, May 2, 2012 at 3:51 PM, Chris Hanson <email@hidden> wrote:
> 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
_______________________________________________
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