Re: Conditionally modifying NIBs?

FROM : Jonathan Hess
DATE : Thu May 15 22:36:33 2008

On May 15, 2008, at 4:25 AM, Mike Fischer wrote:

> Am 15.05.2008 um 02:20 schrieb Jonathan Hess:
>

>> As for the original question, you can modify an IB file, to some 
>> extent, using ibtool --import and ibtool --export. For example, you 
>> might consider placing all of your views and objects in the XIB/
>> NIB, and then using these options to control the isHidden property 
>> of various views.

>
> That's certainly the most interesting idea I've heard so far. So 
> with this method I could in theory assemble different nibs into a 
> single one at build time?
>
>

>> That won't be easy though, as it isn't an intended usage of ibtool. 
>> I think the best option here is to make the changes in code, and to 
>> only use on IB file.

>
> I gather that IB is apparently not meant to allow for scripted build 
> processes. It seems to be a purely graphical tool operated manually. 
> For many purposes this is fine. But once you have a complex nib and 
> want to make incremental changes or changes dependent on some build 
> setting it becomes very complicated.


Yes and No. ibtool isn't meant for arbitrarily modifying NIB's, but it 
is meant to be worked into the build process to do things like 
automatically validate NIB's, or automatically preform incremental 
localizations.

>
>
> Even worse IMHO a nib can hide many rather important settings making 
> it very hard to understand for someone who is not the original 
> author for example. This makes nibs very fragile because small 
> mistakes in say connecting things can lead to program errors that 
> are hard to debug later on.
>
>
>

>> Good Luck -
>> Jon Hess

>
>
> Yes thanks! I keep wondering though how companies that make large 
> complicated apps in teams are coping with these limitations. I can't 
> imagine building something like Photoshop using nibs for everything 
> and working on a nib with more than one person. I'd guess one would 
> use nibs for simple things and possibly building blocks and do 
> everything else at run-time where what happens is clear and self 
> documenting.


Just like small source files that only aggregate related functionality 
help keep source code readable, the best way to keep your NIB files 
maintainable is to keep them small. Take a look at the contents of 
Interface Builder.app in Xcode 3.0, it's filled with hundreds of small 
NIB files. Most controller's go with exactly one view or window, and 
if you can, it's best to keep the NIB files to one top level view or 
window + one main controller (not counting controllers used for 
bindings). If you have a large window with many different sub-
components, consider breaking the subcomponents out into separate NIB 
files with just top-level views. A good rule of thumb is probably that 
if a piece of UI requires its own custom controller (in the classical 
sense, not the bindings sense), it should probably have it's own NIB. 
If you do this, it usually makes your NIB files relatively easy to 
understand, and greatly reduces the chances of conflict in your SCM 
system.

Good Luck -
Jon Hess

>
>
>
> Mike
> --
> Mike Fischer    Softwareentwicklung, EDV-Beratung
>                                Schulung, Vertrieb
> Note:            I read this list in digest mode!
>      Send me a private copy for faster responses.
>