Re: 2 Cocoa Method Questions
Re: 2 Cocoa Method Questions
- Subject: Re: 2 Cocoa Method Questions
- From: email@hidden
- Date: Thu, 16 May 2002 09:30:33 -0700
email@hidden wrote:
|This is from an experienced Mac developer, who is a newbie to Cocoa...
|
|1) When creating non-document Edit/preference style window, what is the best
|method of handling the User Interface vs Content?
|
| At WWDC, one apple engineer explicitly said that you should load the User
|interface when you need them (ie. opening window), and get rid of it when the
|window closes. Each window would have it's own Nib file. This makes sense,
|until you look at the Apple provided programming examples.
A classic example of "do what I say, not what I do." (It's not like this is new. Apple's software often violates Apple's own guidelines.)
Here, the engineer is right: the content and the UI should be as separate as you can make them. This makes for a much cleaner design (and "cleaner" generally results in fewer bugs). The general theory is to keep connections between things as few as possible. By keeping the content and the UI separate, you can more easily change one without affecting the other.
In addition, by keeping content and UI separate, you can keep the content in the format best suited for what you want to do with it, rather than what the UI needs. As a simple example, the content might be a list of numbers, best stored as binary, so you can do arithmetic on them. The UI would need those numbers represented as text, since people don't read binary well, which is a lousy format for doing arithmetic. This is a general rule: the "ideal" format for content is rarely the same as the "ideal" format for the UI. (This is true even for something so basic as preference settings. For instance, a preference might specify a font to render text in. The "content" would be an NSFont object, but the UI would use the name and size of the font.)
The formal name for the design philosophy espoused here is "Model/View/Controller" (or "MVC" for short). The "model" is your content, along with whatever means you provide to meddle with it. In an object-oriented design, the model object(s) will provide methods which other code can use to change the content. The "View" is the UI proper, the objects which accept user input, or which render data for user inspection. These objects have no direct connection with the content (model) objects; they just show whatever they're told to show. The "Controller" objects tie everything together. They keep track of what the user is doing, and translate user actions into model method calls. They also extract from the model the data the UI is to show, and give that data to the view objects to render. Hence, the model objects "understand" how to modify your content; the "view" objects understand how to interact with the user; the controller objects provide the Big Picture, translating user act!
ions into content changes, and content changes back into view changes.
In the context of preferences, the preferences would be the model, the content. The view would be the window which shows the preference settings, in whatever form is clearest to the user. The controller would (probably) be the window controller; it would fill in the UI objects with the appropriate preference values, and would interpret user actions to change the settings, and would then reflect those changes back to the view (UI) objects.
(Notifications are a very useful tool in this approach, because they provide a way for the model objects to trigger controller and view actions without requiring that the content objects be aware of the other objects' existence. The model objects simply send out notifications as the content changes ["paragraph added", "background color changed", etc.], and assume that anything that cares is "listening". I bring this up because I've only recently discovered just *how* useful they are.)
For what it's worth, none of this is particularly Cocoa-specific. The MVC design style can be used with any language, any framework, and any application. (Indeed, application frameworks--of which Cocoa is an example--are almost invariably designed using the MVC approach.)
|2) When creating new User Interfaces, and controller objects, should you
|use Project Builder to write the template of the controller you are
|creating (usually subclass of NSObject)? ... OR ... Do you use
|Interface Builder to create a new subclass, add the needed outlets and
|actions using the Interface Builder UI, and then create the .h & .m
|file needed for this new object?
I generally do all the class defining in PB, because I have a certain layout I like all my headers to use. IB doesn't produce files in that layout, so I'd have to go and edit the IB-produced headers anyway. PB, on the other hand, lets me use "file templates" to create the new headers already set up the way I like. In addition, I find it's easier to add comments describing the various UI objects as I add them, since the comment is added at the best possible time, when I'm thinking about what the UI object does. Also, it's often the case that I'm thinking about the implementation at the same time as the UI elements, so I may add non-UI instance variables as I add the UI stuff, along with the methods that will manipulate everything (which usually includes more than just the action methods that are all I can define in IB).
|The books and examples (and tutorials I seen) use both method, but I am not
|sure if it is just because some were written 2 years ago, vs. recently.
It's not so much how long ago they were written as the preferred working style of the author.
Glen Fisher
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.