When to create a view via a xib and when to create a view via code? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

The question is simple, I guess. I'm looking for general rules of thumb.

I was even wondering if it's possible to create a view controller with a view described in code, but designed in a xib. (Makes sense?)

Closing the question

Although @mckeejm gave an answer where he thinks he had no choice but using code instead of a xib, the question hardly has only one correct answer and it is also very hard for one person to give a response with all the possible correct answers in it, therefore I'm voting to close my question. But thanks anyway.

Answer 1

One thing you can do when you create views without a .xib file is have views that are derived classes of other custom views. For example, in the application I'm working on now, we have the concept of "cards" where cards have a corner radius and shadow setup prior, with a plain UIView *contentView for the actual content of the card to be placed in. If we want to make a new card, without reproducing that code, we simply create a new class that inherits from CardView and then manually position its content via layoutSubviews. I personally like having a .xib for constraint positioning and things like that, but I couldn't find a way to use our CardView as a base class for the new card style control unless we did it programatically.

Answer 2

Yeah what you can do is make a UIViewController in the storyboard file and connect that to a UIViewController class of your choice. Make the basic design in the builder then in the code you can go through and "customize" it to your need. I.e: when a button is pressed change an image. Does that answer your question?

Answer 3

@crimsonchris is right, this question is too open.

I will say this though: I've built apps that utilize storyboards, xibs, and flat out code. I've always found that writing things out in code is simply the fastest, most lightweight solution. BUT it has to be done correctly. My particular method to get ahead is by subclassing.

Typically, you have a consistent style guide in your app and can reuse a lot of ui elements throughout your app. The downside to writing everything in code is that it requires so much redefinition of object's attributes (font, text color, etc). If you subclass a baselined ui class of say a UITableViewCell you can use it everywhere and don't have to deal with the xib/storyboard nightmare. Not to mention the massive speed difference...

Answer 4

If you are a member of linkedIn, there is an IOS developer group that you can join that is probably more appropriate for questions of this type (coding styles). In the linkedIn group the discussion for this same question is already several pages long.

Personally, I use the XIB for its basic layout capability so I can visually gauge if the view looks good or not. Interface builder is not always an answer specially if you have dynamic screens with several layers - in which case I sometimes use a temp IB just to get the coordinates but build the view via code. Take note:when you use a XIB, the objects in the screens are instantiated by the XIB and is a black box to you - so if I have dynamic views with several objects that appear conditionally, using a XIB will create all those objects before your viewDidload whether or not those objects are eventually useful or not. Necessarily it will affect the way you debug, specially if the problem originates from within the XIB.

storyboards allow you to prototype without typing any code, which means you can show your boss how the app should look like within a few hours, I find it limiting in the way I am able to pass values and embedded class instances between class to class so I hardly use it. It is extremely useful if you can work within its boundaries.