1

It's a duplicate of this question.

I was having trouble grasping some Cocoa fundementals (in particular, Controllers and Delegates), so I decided to complete a basic tutorial. I found a 'Your First Mac Application' and all went well until "Where To Next" stage. Here's a bunch of presumably basic things that I don't understand about it:

>

  • "Create a new controller class, and move for managing the track and the user interface from the application delegate to this new class."

...What's the point in creating a separate controller class? I get MVC pattern and used it in the past, I just can't figure out the place for separate Controller and Delegate there.

  • "Create an instance of the controller class in the nib file, and make appropriate connections to and from it, rather than to and from the application delegate."

...Prior to that point I just thought that I just create a subclass of NSWindowController and then declare in .xib file that the window should be the object of this class. Now I'm consused. What class should the controller be? What interfaces (sorry, protocols) should it conform? If it's just a class that I point outlets to, then once again — what's the difference from the Delegate that I already have?

  • "Add a connection from the application delegate to the new controller object. When the application has finished launching, the application delegate should send a message to the controller to display the window."

...What's the message? The closest thing I found is showWindow: message in NSWindowController class, but when I write this:

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {

    [trackController showWindow:self];

}

in applicationDidFinishLaunching method of AppDelegate, it shows error "Receiver type 'TrackController' for instance message is a forward declaration', and I just can't understand what does it mean.

More than that — why should I send a message to show this window at all, if this window shows without any code at that I create all, in a blank project? Maybe I should somehow turn off this default behavior and create an instance of this window myself?

Community
  • 1
  • 1
Max Yankov
  • 12,551
  • 12
  • 67
  • 135

1 Answers1

1

The point for a controller class: it's good practice to keep some ratio between controllers and elements of your model and their user interface. For simple applications you can possibly put all your code in the AppDelegate. Once you develop more complex apps, you will want to offload code from the AppDelegate to various controllers and you will have various views for maintaining your model. I try to maintain a 1:1 relation between view and controller to keep matters manageable.

Controllers can implement various protocols to handle specific bits of functionality on behalf of a UI component. They then become delegates of that component. For example, in your view you have an NSTextView and you want to know when the user clicks a link in your text. Your controller could then implement <NSTextViewDelegate> and implement the method textView:clickedOnLink:atIndex:. By doing so it became the delegate of your NSTextView.

What class should the controller be? There's a wide array of controller classes available for structuring your app. I tend to use only NSViewController. This controller is capable of handling instances of NSView which are displayed in an NSWindow. The view hierarchy supported by NSView allows you to decide for various scenarios of granularity (huge, complex controllers or fine grained - it's up to you).

For the forward declaration issue see this post.

I don't understand your last question re displaying the window. Apparently the default template generates some plumbing code to display the window. You can use that code or roll your own. Clarify if I did not understand you correctly...

Community
  • 1
  • 1
Roger
  • 4,737
  • 4
  • 43
  • 68