iOS 10用于定义UI的Swift和最佳实践

Question

我正在Swift中开发iOS应用程序。我创建的另一个应用程序是我在Objective C中完成的一个应用程序，并且在2014年这个时候发布。故事板似乎使UI的功能同时更容易和更复杂，因此我试图从当前的最佳实践出发的观点发展。

对于多种屏幕尺寸，尺寸类别和约束似乎几乎成为此时的必要定时器。早在2014年，这种情况就不那么严重了，并且以编程方式跟踪UI布局，因为CGRect代码通过程序化方式使UI布局变得更简单，更好地用于代码重用VS创建全新的视图控制器，以便将新的UI元素添加到大致相同视图。用约束代码做同样的事情似乎不太吸引人，但如果我想要更多的代码重用，也是必要的。

所以我想知道当前的做法是什么，因为我只是在考虑代码重用。编程约束看起来不如故事板定义的优雅，但我不确定它们最终都是用于UI代码的，因为它们在程序上动态更新UI似乎有问题。

在这一点上，最好的策略是将所有内容都包含在布局中，保留超级视图并保持大部分故事板为中心，或者对于为这些布局执行swift编程代码仍然有意义，因为我必须为iPad和iPhone指定特定无论如何改变？关于这个话题，将大量不同的用户界面分成多个故事板（例如2个不同的iPad和iPhone故事板，因为这是一个默认设置）还是有意义的？

在此先感谢您的答案。设备特定的东西似乎并不总是代码重用，但我只是想重用相对简单，我猜。否则，我只是创建比我严格需要的更快的类。

Answer 1

这本质上是基于意见的。从Interface Builder到只有StoryBoards的所有东西都可能用于生产应用程序，并且您可以使任何工作都可以实现。

我个人的倾向是将Storyboard用于除TableView/CollectionView单元以外的其他任何东西。我发现它从我的类中删除了几乎所有的接口样板代码，并使它成为我只需要处理ViewController之间的接口。以下是指引我一般尽量并按照：（再次...意见）

• 以有用的方式组织使用多个故事板：

大故事板变得难以维护和性能，同时编辑遭受显着。我们可以选择使用StoryboardReferences，所以不妨使用它们。

• The Scenes和ViewControllers越多越好。 （合理范围内）

这使得事情更易于维护和重用。例如。一个头可以在多个场景中使用。使用containerVCs并处理各地的segues可能有点烦人，但我很少后悔将某些东西分离到它自己的ViewController中。

• 不要为不同的大小使用单独的接口文件。

这是更多的代码来维护，如果你想支持调整iPad上（或任何未来的设备），将迫使你换ViewControllers进出。更何况前进很明显苹果假设你使用的大小类，而不是交换ViewControllers和显然是在未来的苹果平台开发的发展方向

• 当你需要的动画，尽量缩小它改变一个约束。常量

这极大地简化了你的代码，并且通常避免了在故事板以外的任何地方处理大小类。对于复杂的动画并不总是可能的，但如果你愿意乱搞，你可以做出惊人的数量。它可以将切换操作缩小为2行代码，这非常好。使用StackViews也可以帮助你很多。

重点关注的另一件事是避免尽可能多的IB的字符串类型的性质。在Swift中这很容易，并且有一些体面的解决方案使用字符串支持的枚举和扩展，但具体可能超出了这个问题的范围。