disadvantages of using nib

[acc]

Hi,

I have just started iphone development and had a question regarding nib.

Is using nib recommended? Or adding views programmatically is better.

If nib is used, is cocoa framework thorough enough so that the application using nib can handle following situations,
1. If view change dynamically (some controls hide / disable /
enable / change in color / etc)
2. If reusable components are to be made..

Anybody who experienced a situation where IB didn't worked..

Thanks in advance..

Regards.

[Meredi86]

Yes a nib will cope with both. and you can use the code to set parts of your nib file.

Example:

you have a label in your .xib file. you want - on a button push - this label to be hidden from view.

So in your code you set an iboutlet for the label:

@prop.....  IBOutlet UILabel *theLabel;

Then in the code for your button push you have this:

- (IBAction) aButton : (id) sender {
self.theLabel.hidden = YES;
}

The same goes for changing colours and images etc etc, but the syntax is obviously different.

What do you mean by a reusable component? Are you thinking of say a tableview cell? As those also get affected if done in the .xib.

My app uses nib files for almost everything, each view has one, and rarely have i set objects on that view through the code - most is laid out in the .xib and hooked up through the .h. If you have something that you want to affect from the code that is in the xib you just need to hook up and IBOutlet or an IBAction depending on the task (hint the IB in both the previous terms stands for Interface Builder)

As for advantages and disadvantages, that is interesting and VERY subjective. There are people here who really do have a problem with IB and there are some who have a problem with just using the code. there is little one can do that the other cant do, although generally in that thought code can sometimes provide better control - this i think is also subjective as i have used and played about with everything in IB at some point or another and i am yet to come across some functionality that is limited in IB (i exclude games here as that requires graphics and more than a few UI elements).

So to conclude my short advantages vs disadvantages this is what i would say - learn them both. I am starting on IB - it is a much faster learning curve and can allow you to roll out an app a lot faster (from a noobs perspective that is - id still consider myself 60% noob) but for the future and for moving to bigger and better apps i would suggest getting a good grasp on how to do it all via code. that way you can make your own decision on which you prefer, and you can have the best of both worlds!

Hope that clears a little bit up - may even spark a little more debate as those who know more then me come and say how wrong i am for liking IB :P

[acc]

Thanks for the info..

Yes, may be with using iphone sdk more, I would know more on advantages and disadvantages of nib. May be others who are already more experienced can share their take on this further...

And by reusable component, I mean to say that,
If I implement some UI using nib, and now I want to reuse this whole component in some other application (with further customization allowed), will this be possible.

Regards.

[nobre84]

IB UIs are exactly the same as programmatically laid UIs. They both have the same objects and hierarchies. IB is faster and easier to create and can be easier to maintain. However you can have more freedom to create complex or very dynamic features by code. You can easily combine those 2 approaches. For instance if you have a very complex UI element that is to be added to your views on demand, you can create the complex element in code and add instances of it to an IB view (you just add a regular view and change the Identity class to point to your custom View)

[iSDK]

The only real advantage of IB is that you can easily drag the interface object around in the view to where suits you. I find setting the frame of a non IB setup object can be a real pain sometimes.

[acc]

Thats true..

Using IB is simpler. The other side that comes in is, whether implementation through IB support,
1. Generalization / Extensibility (If code using IB is to be reused / extended)
2. Dynamic and complex UIs.

In general, what is that cannot be done through IB that only needs to be done through code.

Anybody who experienced a situation where IB didn't worked..

[Meredi86]

Yup. On one of my views i had to place some images via code. Even though they were correctly sized (there are 3 all the same size) and in the correct format i just couldnt get them to place properly without using code to place them. So my "home" page is programatically made.

Sorry i cant go into more specifics now, it was well over a month ago i came across this problem

[dapis]

I never can understand why there is any discussion on this matter.

Interface Builder is a very powerful and useful tool and to not use it when appropriate would be insane. Moreover, you can easily modify any views loaded from nib's in your source code. With the extra convenience of having it built in to XCode 4, it has become even better.

That said, there are occasions when the view is best designed and loaded in code. I've done it both ways, but certainly I use IB whenever I can.

The bottom line:
Interface Builder is a useful tool and a time saver; use it whenever its appropriate.

[Meredi86]

I never can understand why there is any discussion on this matter.

I am sorry to say but you clearly do understand why there is always a discussion on this:

Interface Builder is a useful tool and a time saver; use it whenever its appropriate.

Not everyone know when and what is appropriate. So they ask questions about it. I know when i started and was looking into this debate there was little information that would have answered the questions i had about it.

As for me i am surprised that a few more of the "big guns" of the forum havnt dropped in to make their suggestion - though maybe thy are a little tired of the same discussion.

for a noob this is daunting stuff, there are questions you have that no-one else seems to have asked, not because they are more intelligent, not because you are more intelligent, but you just thought of a new question for it that suits your needs at the time.
I guess for a seasoned iOS developer though it is an easy choice that is clear cut by certain factors. again factors that are specific to the task in hand. Possibly this sort of discussion just seems a little too simple to post on.

Who can really answer it all eh? I think for now its best the forums are used to keep asking these things - its what they are here for :P

[acc]

Originally Posted by dapis

That said, there are occasions when the view is best designed and loaded in code. I've done it both ways, but certainly I use IB whenever I can.

This is what the intention of question is.. to know the occasions where IB would not work.. if such is the case, based on everyones experiences.

Can you please share more details as to what occasions did you find IB not at work.

[harrytheshark]

This might be worth a read: Cocoa with Love: Load from NIB or construct views in code: which is faster?

[BrianSlick]

Originally Posted by harrytheshark

This might be worth a read: Cocoa with Love: Load from NIB or construct views in code: which is faster?

Interesting. This predates UINib. It would be interesting to re-run those experiments.

[dapis]

Originally Posted by acc

This is what the intention of question is.. to know the occasions where IB would not work.. if such is the case, based on everyones experiences.

Can you please share more details as to what occasions did you find IB not at work.

Basically, I cannot see any reason to avoid nibs. IB is a huge time saver. There's no advantage that I can see in being macho and doing it all in code.

The golden rule would be to use it until you find a reason not to - perhaps something is not working as you expect and you need to take control from code.

In general, I use IB and then make customizations to a view in the viewDidLoad call (that's what it's there for, after all )

If you choose to use cocos2d then, you'll be restricted in your use of IB.

[BrianSlick]

Don't fear the Interface Builder