添加视图。故事板VS.编程 [英] Adding Views. Storyboard VS. Programmatically

问题描述

我和这个人一直在斗争很长一段时间。
假设我有一个UIViewController，需要在该控制器中放置一个带有UIImage的UIImageView。
所以我有两种方法可以做到：

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。）通过故事板

2。 ） UIImageView * imageView = [UIImageView new];
imageView.frame = CGRectMake（bla，bla，bla）;
[self.view addSubview：imageView];

另外我需要支持不同的屏幕尺寸（从iPhone 4到iPhone6 +）对我来说，带有约束的自动布局并不完全清楚。而且我很喜欢

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

我觉得我做错了什么。
当我开始学习objective-c时，我看到了一些开源项目，并且根本没有故事板，所以我认为以编程方式添加视图是一种很好的做法。

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" ?

推荐答案

我会说大多数时候自动布局的故事板是最好的选择。它有许多优点：

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

• 它将表示与逻辑分开。在控制器中创建整个界面通常是一个糟糕的设计。对于简单的接口，以命令式方式声明它们会带来很多开销。通常，您最终会有数百行代码，可以在10分钟内完成故事板或xib中的操作。

• 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.

通过故事板，您可以获得一个精彩的WYSIWYG编辑器，您可以在其中查看屏幕在不同设备上的外观，而无需重建项目并在数十台设备或模拟器上运行。 嗯，不是几十种，而是针对iPhone的iPhone和2种分辨率的4种不同分辨率仍然很多。此外，视网膜和非视网膜屏幕之间的文本大小和渲染可能存在微小差异

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。当然，你也可以在代码中使用它，但默认的苹果接口对它们来说很糟糕。有一些第三方库使得使用自动布局更容易一些，但无论如何使用故事板你都不会担心代码中的自动布局在大约80％的时间内。剩下的20％就像是向控制器添加约束出口，然后用一行代码改变它的常数或优先级

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

大小类。再次，你可以在代码中使用它们，但是你可能不需要使用故事板。大小类允许您为所有可能的设备形状因子，不同的设备方向等设置单个接口。在大小类之前，开发人员必须拥有2组不同的iPhone和iPad接口。

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.

但是，某些地方的故事板不是实现目标的最佳方式。例如，如果您有一些在应用程序的不同位置使用的视图。只使用故事板方法，您必须在许多地方拥有此视图的副本，因此在对其中一个进行更改时，您必须记住在其他副本中进行此更改。在这种情况下，最好使用具有此类视图的单独的 xib 文件，然后在故事板中使用它。

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.

此外，自动布局可能相当性能昂贵。因此，如果您的应用程序开始滞后并且您确定（ with profiler ）自动布局例程是滞后的原因 - 那么手动处理代码中某些视图的创建和布局可能是有意义的。但这可能只是一个非常复杂的接口。大部分时间表现都不是问题。

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.

你说autolayout对你来说并不清楚。这不是拒绝使用它的理由。你需要做更多的工作才能让所有设备上的应用看起来都不错，而不需要自动布局。你看到的一些开源项目可能是为第一批iPhone（4s及之前的版本）编写的，它们都具有相同的分辨率，所有尺寸和位置都可以硬编码。现在，正如我先前所说，我们已经有了十几种不同的分辨率。并且手动处理所有代码是一个真正的困难。 Autolayout会让你的生活变得更轻松：）

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 :)

此外，你可以看看这些关于何时何地使用故事板，xib和手动视图处理的争论： http://www.raywenderlich.com/51992/storyboards-vs -nibs-vs-code-the-great-debate

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

在同一个网站上（ http://www.raywenderlich.com ）您还可以查找autolayout教程以更好地理解它。

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

这篇关于添加视图。故事板VS.编程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！