I think I'm missing something, too


#1

After I finished reading the book and working through the exercises, reading some of Apple’s example programs and trying to write some good small example programs myself, I am well aware that I still have much to learn. One crucial matter is how to structure (factor) Cocoa programs in a good, standard, way. I’ve seen the thread “Am I missing something?” started by drtyrell, and I think I understand what [s]he is trying to say, but have a follow-on question. This is: it is, I’m sure, good practice to have a separate instance of a subclass of NSViewController to manage each complicated view in a program, but how exactly to code that in the best way? (There are hints elsewhere on the web, but I think the book should cover this.) A complicated view might never move from its initial position in the document window, so we’re not talking about view swapping.

The Chapter 12 example - “Adding a panel to the application” - introduces an AppController (a term not found in the book’s index) and a window with its own instance of an NSWindowController. Chapter 31, "View Swapping’, would be better - IMHO - if it was preceded by an example of adding a view to the window (with controls/subviews as needed) which was managed by its own instance of an NSViewController. I’d like to see how best to combine the program’s subclass of NSDocument, the AppController, the complicated view’s instance of the NSViewController and the complicated view. Instead, we leap in 31 straight into the more specialised situation of alternate views presented in an NSBox owned by the document, and the AppController has vanished - so, how to combine the ideas of Chapters 12 and 31?

Chapter 30 - “Developing for iOS” - has more on alternate (UI) View Controller instances controlling separate views, there being no NSWindowControllers for iOS. Perhaps the idea of separate view controllers for complicated OS X views could be introduced before that, and the iOS chapter be made optional?

Can anyone recommend a really simple (short!) but complete example bit of code of good practice for what I want to do?


#2

Thanks for your post – you raise some good points that we will work to improve upon in the next edition of the book.

As for how to use an NSDocument and NSViewController together, basically you will create an instance of the view controller within the document class. Usually you will set a model object on the view controller so it knows what to show. I’ve created a demo application to show this: https://github.com/preble/ViewControllerDemo. You can download it using the Downloads link on the right hand side.

You mentioned AppController - in a situation like this there is no need for involvement of an application controller. The NSDocument subclass plays the role of the window controller, and the window controller is generally who will be performing UI setup like this. The app controller (called the App Delegate by the Xcode templates) is usually responsible for creating windows, such as the Preferences window.

Please let me know if you have any further questions.

Adam


#3

Why, thank you Adam! I’ve fetched your demo program from GitHub and built it. I’ve not had time yet to study it in detail, but it looks far cleaner (of course) than my attempt at a solution. After correctness and algorithmic efficiency, I’m convinced that it’s good factoring that makes a better, more maintainable, program - and that makes it easier to reason about program correctness.

Part of my problem - early on, before I realised that it was making things too complicated - was to think that the ‘AppController’ instance had to be the central controller for the entire app, so I’d put the viewController instance inside that. But I knew that the instance of my NSDocument subclass was for document management, and couldn’t reconcile the division.

Excellent book, of course. You must be busy rushing to keep up with Apple’s policy of continual improvement in the things the book describes.

Many, many, thanks!