Adding Views. Storyboard VS. Programmatically

Adding Views. Storyboard VS. Programmatically

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.

Storyboards and programmatically views

Yes you can create a StoryBoard with a view and then add views programmatically to it.

You should not try creating a view within your prepareForSegue method. This really should be used for passing objects to another ViewController.

I would suggest this to you. Go back to your StoryBoard and create a new UIViewController scene. Click on your first scene and CTRL drag to the new scene. Next, click on your segue and give it a name.

Step 1:

Create a new class called ServicesViewController and make sure it's a subclass of `UIViewController:

Step 2:

Go back to your StoryBoard and click on scene so that it is selected. Next, click on the Files Owner and finally click on the class info button (the third button) and finally select your ServiceViewController class you just created.

Step 3:

Back in your ServicesViewController in the didSelectRowAtIndex method call your seque:

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    [self performSegueWithIdentifier:@"YOUR_SEGUE_NAME" sender:nil];
}

For now, clean out all the code in your prepareForSegue method and just get the transition down first.

How to display elements added programmatically on a storyboard?

No,it is not possible to see a programmatically added component to appear within a storyboard.

A storyboard is a visual tool for laying out multiple application views and the transitions between them. Internally it is represented an XML file.

The component added programmatically is a separate file and the storyboard is a separate xml file.

Storyboards vs. doing it in code

I'm going to split your question into two: NIBs, and storyboards.

As far as NIBs are concerned, source control issues can be painful but manageable, mainly because you've typically got one NIB file per view controller. You could imagine a situation where you have two developers working on two different sections of your NIB powered app without any merging issues. Storyboards are different, since you have one single file that describes most - if not all - of the UI of your application. Clearly there is a far greater potential for conflict issues there.

NIBs can be extremely useful and time saving, if used correctly. Here's an example: the iPhoto App on iPad has a very complex UI. The vast majority of that UI is laid out programatically. However, the app also uses NIBs to load in graphical elements which are then laid out in code. This is how the brush panel works - all the brushes are created in a NIB. This means that Apple don't have to have dozens of identical image/image view alloc/init pieces of code. All the creation can happen in a NIB (this was discussed in some detail in a WWDC 2012 session on the iPhoto UI - it's well worth tracking down).

So NIBs - sometimes good, can save you a lot of time, and whilst there are merge issues they can in many cases be easily managed and handled.

Then we come to storyboards. Storyboards are interesting. On the one hand, they are extremely helpful and useful for straightforward apps and developers new to the platform. I've just converted a UINavigationController based app from NIBs to storyboards and found some significant time savings (particularly around table views, since with storyboards you can take advantage of prototype cells).

However, if you're working on a large scale project with several developers I'm not convinced storyboards are that beneficial. There are, as you say, big issues with merge conflicts, and unlike NIBs it's not easy to resolve them since that single storyboard file controls all of your app UI.

Here's what I'd suggest (and feel free to ignore me!) - if you're currently developing apps and doing your layout/UI entirely in code consider whether NIBs might save you time. They may well not - they're not for everybody - but it's well worth at least considering. You may be surprised at how many large apps actually use NIBs (iPhoto, as I mentioned, but also many built-in apps provided by Apple, as well as many popular third party apps by large teams). I probably wouldn't consider storyboards unless you were a sole developer working on an app with fairly straightforward navigation. That's not to do down storyboards in any way - I love using them - it's just they're not really suitable for collaboration.

Somebody posted this comment in reply to your question - I wanted to discuss it:

There is nothing you can do in storyboard and can't do in code. Objects, gesture recognizers, segues, even constraints - are all available for you to build programmatically

This is technically true, but in reality there are things in storyboards/NIBs that are much easier than code. A good example of this is auto layout. Whilst you can certainly manage your auto layout contraints entirely in code, the harsh reality is that the ASCII auto layout representation is much harder to work with than the visual representation you get in IB. This is especially true on XCode 5, where there are massive improvements to auto layout in IB (I can't detail it too much as it's still under NDA, but Apple publically talk a bit about the changes here).

---

Related Topics