Adding Views. Storyboard VS. Programmatically [closed]

Question

I have been in a struggle for a long time with this one. Lets say I have a UIViewController and need to place an UIImageView with an UIImage in that controller. So I have two ways to do it:

1.) Via Storyboard

2.) UIImageView *imageView = [UIImageView new]; imageView.frame = CGRectMake(bla, bla, bla); [self.view addSubview: imageView];

Also I need to support different screen sizes (from iPhone 4 till iPhone6+), and autolayout with constraints isn't fully clear for me. And I'm sh*tcoding like

int wrapperHeight = (screen.height == 480) ? 100 : 200

I feel that i'm doing something wrong. When i started to learn objective-c, I have seen some opensource projects, and there was no storyboard at all, so i thought that adding views programmatically is a good practice.

Could you please explain me the "right way" ?

Answer 1

I'd say that most of the times storyboard with autolayout is the best choice. It has a number of advantages:

• It separates presentation from the logic. Creating the entire interface in a controller is usually a bad design. And for simple interfaces declaring them in an imperative way brings in to much overhead. Very often you'll end up having hundreds of lines of code for the interface that could be done in a storyboard or xib in a 10 minutes without any effort.

• With storyboards you have a great WYSIWYG editor, where you can see how the screen will look like on different devices without having to rebuild the project and run it on dozens of devices or simulators. Well, not dozens but 4 different resolutions for iPhones + 2 resolutions for iPads stills a lot. Also there may be tiny differences in text sizing and rendering between retina and non-retina screens

• Autolayout. Of course, you can use it in code as well, but default apple's interfaces for them suck. There are some 3rd party libs which make working with autolayout a bit easier, but anyway with storyboards you're not gonna worry about autolayout in code at all in ~80% of the times. And the rest 20% would be just something like adding constraint outlet to the controller and then changing it's constant or priority with a single line of code

• Size classes. Again, you may work with them in code, but with storyboards you'll probably wouldn't have to. Size classes allow you to have one single interface for all possible device form-factors, different device orientations, etc. Before size classes developers had to have 2 different sets of interfaces for iPhones and iPads.

However, there are certain places where storyboards aren't the best way to achieve the goal. For example, if you have some view that is used in different places of the app. With storyboards-only approach you'd have to have copies of this view in many places, so when making changes in one of them - you have to remember to make this changes in other copies as well. In such cases it's better to use a separate xib file with such view and then use it in a storyboard.

Also, autolayout may be quite expensive in terms of performance. So if your app starts lagging and you determined (with profiler) that autolayout routines are the reason of the lags - then it may make sense to handle creation and layout of certain views in code manually. But this could be the case only for a really complicated interfaces. Most of the times performance wouldn't be an issue.

You said that autolayout isn't clear for you. That's not the reason to deny using it. You'll have to do a lot more work to make an app look good on all devices without autolayout than with it. "some opensource projects" that you saw could have been written for the first iPhones (4s and before), which all had the same resolution in points and where all sizes and positions could be just hardcoded. Now, as I said earlier, we've got almost a dozen of different resolutions. And handling that all in code manually is a real struggle. Autolayout would make you life easier :)

Also you may take a look at these debates about when and where to use storyboards, xibs and manual view handling: http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate

And on the same site (http://www.raywenderlich.com) you could also look up for autolayout tutorials to understand it better.

Answer 2

Both ways has its own advantages, as a programmer you should be comfortable with both, and to use which one depends on your situation, sometimes its easy to use storyboard/xib and sometimes its easy to build view programmatically

Some advantages of creating views programmatically -

1. Better to work with team. It's easier to merge code and resolve conflicts when committing to a repository than it is in case of storyboard.

2. When debugging it's easier to trace errors and you don't have to look to IB.

3. Creating views programmatically gives you more control

Some advantages of adding views in storyboard -

1. It's faster to develop view in storyBoard, it helps you to put everything together, like centering views,aligning them, connecting their actions etc.

2. Your code is not crowded with UI related stuffs, so you have much cleaner code.

3. Also for people who just start developing apps, its pretty easier for them to use storyboard, and gives them confidence as they can see things they are building.

Bottom line is it depends on your situation and you should choose wisely, suppose you have static UI that doesn't change much or animate, its always easier and faster to use storyboard, but if you have some dynamic UI like it has lot animations and you need to manipulate your constraints then its easier to build your UI programmatically

Also keep in mind that XIB file loading time is longer than build UI programmatically.