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 <c...@me.com> wrote:
> On May 2, 2012, at 6:19 AM, ecir hana <ecir.h...@gmail.com> 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 (Cocoa-dev@lists.apple.com)
>
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/colo0logo%40gmail.com
>
> This email sent to colo0l...@gmail.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
