3

I'm stuck on this step of developing an XCode application: https://developer.apple.com/library/mac/#documentation/General/Conceptual/Mac101/Articles/07_WhereNext.html

What I'm confused about is the role of the AppDelegate class that's created by default when creating a project initially in XCode 4. If I implement a custom controller, let's use the example link above and call it TrackController. Do I make that controller the app delegate? It seems any tutorial I read isn't very clear on this.

So, in AppDelegate, do I create a new instance of the controller class here? And if so, do I then hook up the outlet here? Or do I change the File's Owner to be the controller class? If that's the case, then how's that done in XCode 4?

Not a very well defined question I know, but I'm sure someone knows what I'm talking about.

EDIT

The following screenshot shows what I mean. The blue box is now "Track Controller". I've shown the AppDelegate class in this case though to make it clear. What do I use, AppDelegate.m, or TrackController.m? How should it be done?

enter image description here

EDIT 2

Going back to this, I've uploaded the code to GitHub here as I still haven't figured out how to hook everything up.

To re-explain, I need to figure out how AppDelegate and TrackController all relate and communicate with one another. The concepts are generally new to me and I've read the Apple documentation but they haven't really helped me. I've even had in-depth discussions with experts and I still fail to see how it should work.

My model is Track, then I have TrackController and of course AppDelegate. AppDelegate is instantiating TrackController and I was hoping that it'd be able to open up its window.

What am I doing wrong? Hopefully an expert can help me!

Kieran Senior
  • 17,960
  • 26
  • 94
  • 138

1 Answers1

0

What it's describing is that the application delegate should focus on handling the delegate calls sent to the app.

You actually create a new class to act as the primary controller of the app, and then you add code to call it when the app is finished loading. From there on out, that app is (supposedly) your primary control point (except, of course, when it 'hands off' to another class).

I'm more familiar with how the process works on iOS than Macs, which have to worry about windows, but for an iOS app you'd add code to call your starting view controller from inside ApplicationDidFinishLaunching:WithOptions:. From there, the view controller takes off, and the easiest way to view the entire process is that you start at the view controller (that's how most tutorials handle it, in fact, letting XCode handle the fact that the app delegate creates that view controller).

RonLugge
  • 5,086
  • 5
  • 33
  • 61
  • In XCode, there's a blue box where you set the class for the Interface Builder. If I set that to my controller then does that mean it will use the controller instead? – Kieran Senior Mar 28 '12 at 21:28
  • I don't know what blue box you're talking about, alas. Since you're developing a Mac app, it's possible you're getting different controls than I am. There's also the sheer NUMBER of controls that makes it hard to figure out which one you could be talkign about. – RonLugge Mar 28 '12 at 21:33
  • The blue cube represents an instance of your class. When you start a project there will be one in IB for the default app delegate class. If you add a new class like TrackController and you need to make connections from an instance of that class to UI elements then you drag out a new blue cube and change its class to TrackController. Generally, you mostly use the app delegate class for the methods that are in the ApplicationDelegate Protocol, and possibly for some initial set up or calling other classes to get them started. – rdelmar Mar 28 '12 at 22:25
  • Ctrl+drag a blue cube from the objects list out onto the main UI? – Kieran Senior Mar 29 '12 at 07:38
  • For the controller of a window or view, I usually just change the type of 'File's Owner' to the window controller class, because I always instantiate the nib from the controller and make it the owner (via [super initWithWindowNibName:@"TheNibName"] in the controller's init). When you create an object in IB, remember that you're actually creating a (serialised) instance of that object inside the nib file itself, not a reference to one. So you only want to create new custom objects inside IB for things you want to be instantiated by loading the nib. – Steve Streeting Mar 29 '12 at 09:35
  • Note that the MainMenu.xib that XCode creates by default includes an instance of your AppDelegate because that's how it gets instantiated. This is in many ways an exception - while you might instantiate detail-level objects inside the nib (like array controllers for lists), you rarely create high-level objects like this because they're dependent on the nib being loaded. MainMenu.xib is unusual because it's the top-level nib that the application loader instantiates at startup, as referenced by your main Info.plist. – Steve Streeting Mar 29 '12 at 09:37