macOS Fundamental Interface Builder/views/XIB question

[RossOliver]

Hey,

I've been doing a bit of programming in XCode recently and I can create iPhone applications with multiple views, navigation bars etc easily enough programatically - but now I want to try it with IB.

My question is, how do you model each view in IB? Should I create an XIB file for each separate view and load them in their own view controllers? Say I have a main section with four buttons, each button going to a different view, does this mean I should have five XIB files in total or do I somehow model them all in one?

Thanks for your time,

-Ross

 

[white89gt]

This is something that I have been wondering about, too. I've been studying the samples provided by Apple, and I think that the SQLiteBooks example handles multiple view controllers and multiple XIB's in the "standard" way, but I have yet to dive in and try to create my own multi-XIB program yet. If anyone has any info on how to do this properly, I'd like to know as well.

 

[RossOliver]

I'm glad it isn't only me that's puzzled by this. It would be nice if there was some kind of overview diagram detailing the structure of a generic iPhone application - anyone know of one?

 

[white89gt]

I'm glad it isn't only me that's puzzled by this. It would be nice if there was some kind of overview diagram detailing the structure of a generic iPhone application - anyone know of one?

Yeah, it would be nice.

I've been thinking about this for a while, and the best thing that I can come up with is subclassing UIView to be the View controller the same way you would subclass NSObject when writing apps for Mac computers. Doing that, you could put all your interfaces in the same XIB file and just create multiple controller views to handle their outlets and actions. However, I'm pretty sure that isn't a very Cocoa-oriented way of doing things.

 

[RossOliver]

Can no one shed light on this? I would have thought it is a rudimentary stage for most Xcode/Interface Builder users

 

[Cromulent]

Can no one shed light on this? I would have thought it is a rudimentary stage for most Xcode/Interface Builder users

The Apple documentation is very clear on the fact that you should have the minimum possible in each XIB / NIB file as they are fully loaded into RAM when your application reads the file. If you have all your resources in one file you are potentially loading data into RAM which the user is not going to use in that session. RAM issues are much more important if you are dealing with the iPhone.

 

[RossOliver]

The Apple documentation is very clear on the fact that you should have the minimum possible in each XIB / NIB file as they are fully loaded into RAM when your application reads the file. If you have all your resources in one file you are potentially loading data into RAM which the user is not going to use in that session. RAM issues are much more important if you are dealing with the iPhone.

Could you point me to this documentation? Sounds like it could be useful to read

Thanks

 

[Cromulent]

Could you point me to this documentation? Sounds like it could be useful to read

Thanks

http://developer.apple.com/document..._5.html#//apple_ref/doc/uid/10000051i-CH4-SW4


When creating your nib files, try to keep the following guidelines in mind:

Design your nib files with lazy loading in mind. Plan on loading nib files that contain only those objects you need right away.

In your application’s main nib, avoid including any windows or user-interface elements that will not be used until after the application has launched. Ideally, the main nib file should include the application menu bar and an optional application delegate object only. Other resources can be stored in separate nib files and loaded once the application is launched.

Store repeated user-interface components (such as document windows) in separate nib files.

For a window or menu that is used only occasionally, store it in a separate nib file. By storing it in a separate nib file, you load the resource into memory only if it is actually used.

Make the File’s Owner the single point-of-contact for anything outside of the nib file; see “Accessing the Contents of a Nib File.”

 

[RossOliver]

Ah, that's a great resource - thanks, I'll have a read through