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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
