我正在使用Swift中的iOS应用程序。我创建的另一个应用程序是我在Objective C中所做的一个应用程序,并在2014年左右发布。故事板似乎使UI内容更容易,同时也更复杂,所以我试图找出当前的最佳实践在视角发展方面。
对于多种屏幕尺寸,尺寸类和约束似乎几乎是必要的节省时间。早在2014年,情况就更糟了,并且以编程方式跟踪UI布局,因为CGRect代码以编程方式使用UI布局更简单,更好地用于代码重用,而不是创建一个全新的视图控制器,只需添加新的UI元素即可视图。使用约束代码做同样的事情似乎不太吸引人,但如果我想在那里重用更多的代码,也是必要的。
所以我想知道当前的做法是什么,因为我只是在思考代码重用方面。程序化约束似乎不如故事板定义的那样优雅,但我不确定它们是否完全适用于UI代码,因为它们似乎有问题,无法动态更新UI。
此时最好的策略是将所有内容都包含在布局中保留超级视图并保持大部分故事板为中心,或者为这些布局执行快速编程代码仍然有意义,因为我必须使用iPad和iPhone具体的变化无论如何?关于这个主题,将截然不同的UI分成多个故事板(例如2个不同的iPad和iPhone故事板,因为这是默认的一个点)仍然有意义吗?
提前感谢您的回答。设备特定的东西似乎并不总是代码重用,但我只是希望重用相对简单我猜。否则,我只是创造了比我严格需要的更快捷的课程。
答案 0 :(得分:3)
这本质上是基于意见的。从没有Interface Builder到StoryBoards的所有东西都可能在生产应用程序中使用,你可以做任何事情。
我个人倾向于将Storyboard用于TableView / CollectionView单元以外的所有内容。我发现它从我的类中删除了几乎所有的接口样板代码,因此我只需要处理我的ViewControllers之间的接口。以下是我通常尝试遵循的指南:(再次......意见)
大型故事板变得难以维护和性能,而编辑则明显受到影响。我们可以选择使用StoryboardReferences,所以不妨使用它们。
这使得事情更易于维护和重用。例如。可以在多个场景中使用的标头。不得不使用containerVCs并处理各处的segues可能有点烦人,但我很少后悔将某些东西分成它自己的ViewController。
如果你想支持在iPad(或任何未来的设备)上调整大小,那么维护更多的代码会迫使你进入ViewControllers。更不用说未来了,很明显Apple假设您正在使用大小类而不是交换ViewControllers,而且显然是Apple平台开发未来的发展方向
这极大地简化了代码,并且通常避免在故事板之外的任何地方处理大小类。复杂的动画并不总是可能的,但如果你愿意乱搞,你可以做出惊人的数量。它可以将切换操作缩小到2行代码,这非常好。使用StackViews也可以帮助解决这个问题。
要关注的另一件事是避免尽可能多的IB字符串式特性。这在Swift中更容易,并且有一些使用字符串支持的枚举和扩展的不错的解决方案,但具体可能超出了这个问题的范围。