Re: Guidance on Project Structure
Re: Guidance on Project Structure
- Subject: Re: Guidance on Project Structure
- From: Charles Jolley <email@hidden>
- Date: Mon, 17 Jun 2002 08:57:26 -0500
On Monday, June 17, 2002, at 05:34 AM, Donald Brown wrote:
2. What factors influence the decision to add extra nibs to a project?
(I've looked at OmniWeb's package contents, for instance, and there are
no fewer than NINETEEN nib files in there.) And what methods can be
used
to make them communicate with each other?
I generally divide up my nibs according to a few principles:
Performance.
Your user interface could be kept in one nib file loaded at start up.
This will eat the maximum amount of memory your user interface requires
and it will take the maximum amount of time your user interface requires
to initialize. If parts of your user interface are not needed right
away (such as the preferences panel, palettes, etc.) you might want to
place these into their own nib file and load them as needed. This
reduces memory and shortens start up time (although it will introduce a
small delay when the nib is first accessed.) If your user interface is
not very complex anyway, or if most of it needs to be visible from the
start, then you can probably leave everything in the same nib.
Ex: I am working on a project called Okito Composer.
(
http://www.okito.net/composer) It is a document-based application. The
MainMenu nib holds the main menu and the preferences because they are so
simple right now. Eventually, they will be in their own nib. Other
nibs make up the rest of the document because it is complex and does not
need to be loaded until the user opens a new document.
Another project, Okito Thesaurus (
http://www.okito.net/thesaurus) has a
simple user interface that is basically visible whenever the user starts
using the service. So everything is in one nib file.
Factoring.
You may want to split your nibs according to how your application
objects plug together to make it easier to add and remove parts of it.
For example, Composer uses a set of plug-in palettes that go with every
document. Each of these palettes gets their own nib. I could put them
into one big nib, but then I could not easily add or remove them from my
project. As it stands now I disable a few source code files and the
nibs from my project and I can remove a palette altogether.
For larger projects it is important to factor your application objects
into well-defined parts that are "isolated" from one another and only
work together in a few, well-defined, ways. A well factored application
is easier to build and update incrementally, easier to debug, easier for
multiple people to work on, and best of all, more likely to produce
reusable components for other projects. I have found this to be
especially true with Cocoa.
I suspect this is a big reason why OmniWeb has so many nibs.
As for making nibs communicate with one another:
Objects in a nib file are connected to the rest of the application
through the files owner (which is generally the object that loads the
nib file). Objects in a nib file can also send action messages to the
first responder or you could configure them to listen to notifications.
These each have their place. Generally, the nib file owner should be a
controller object for the nib contents (this can be a window controller
or anything else). If you properly factor your application, most other
objects in your application should deal with the controller, NOT the
user interface objects appearing in your nib file.
Finally, let me state that how you use nibs is largely a matter of
style. I think that once you create an application that uses multiple
nibs and once you start to learn how Cocoa applications should be
designed (using the Model-View-Controller paradigm for applications this
would be useful), you will develop a style that works for your
application.
-C
_______________________________________________
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.