Tag: PavelProcházka

放下故事板

每年在WWDC上，Apple都会大张旗鼓和鼓掌地宣传Interface Builder的新功能，通常是在顶级会议中，例如大型的“国情咨文”会议。 如果您在Interface Builder中布置视图，则是个好消息。 同时，如果您在代码中布置视图，则新功能很少而且相差很远。 iOS 9中引入的关于在代码中创建自动布局约束的新语法的唯一提及是在15分钟内被塞进了名为“自动布局之谜，第二部分”的会话中！ 不完全是黄金时间。 真遗憾的是，Apple没有提倡更多地在代码中布局视图，并且没有以与更新Interface Builder相同的速度来改进这样做的工具。 在代码中放置视图可以真正提高生产力，并且可以很好地提高代码的整体质量。 为什么不只使用Interface Builder？ 有许多原因应避免使用Interface Builder，其中一些原因与编写代码的优势有关，而某些原因与Storyboards和Interface Builder的缺点有关。 我将在这里讨论一些关键问题。 除非我特别提到情节提要，否则下面将仅使用术语“ 界面生成器” ，因为大多数问题都与所有情况有关。 首先，Interface Builder文件只能由Xcode生成和读取。 您可以将文件读取为XML，但是它们没有什么意义，或者至少，XML本身对事物的实际布局没有多大帮助。 当您发生合并冲突时，这会带来问题，对于包含许多视图控制器信息的情节提要，合并冲突会变得非常严峻。 您可以无意中更改视图或视图控制器的布局，这可以通过单击错误或打开文件来实现。 Interface Builder通常只是因为打开文件而对文件进行了更改。 当查看差异时，很难将其与您自己的更改区分开来，也很难进行推理。 换句话说，更改可能很难（在提交之前由您自己审核，而在进行代码审核时则由团队伙伴审核）。 由于Xcode幕后发生的所有变化都会使臭虫迷失，因此臭虫可能会被发现而未被发现。 Interface Builder的一个基本问题是，您在界面中看到的大部分内容都是视图的设计时快照。 您可以修饰视图以使其看起来像实时运行。 例如，从文件或服务器获取并仅在运行时加载的任何数据都必须在设计时进行模拟，并在运行时由实际数据替换，或者完全不在设计之列，这会破坏视觉布局的意义。 。 这将模拟数据与您实际想要显示在应用程序中的设计时数据混合在一起。 换句话说，您必须拆除设计时布局并在运行时构建运行时布局。 仅在设计应用程序时供您查看的数据很容易泄漏并成为运行时数据，这是非常不幸的。 您在Interface Builder中设置的某些属性只是更好地在代码中设置。 为了您自己，或者为了任何人继承您的代码。 颜色和字体是要在代码中以一种或另一种方式定义为常量的事物的绝佳示例。 如果它们将来会发生变化，我不会羡慕那些必须通过所有观点来选择新颜色或新字体的人。 如果您确实在代码中定义它们，则当前无法在Interface Builder中引用它们。 无论您做什么，都会有很多挑选的颜色和字体。 如果在Interface Builder中只保留设计中的字体和颜色，而仅在代码中进行设置，那么这将违反Interface Builder的目的。 代码对Interface Builder中对象的引用通常由字符串标识符组成，在这些字符串标识符上没有编译时检查。 如果您更改，删除或错误拼写了任何这些字符串，则可能会导致应用程序在运行时崩溃或停滞。 如果您没有在发布前测试确切的代码路径，那么您会感到不满意。 当您使用Interface Builder时，Swift由于强大的键入和编译时间检查而带给我们的许多代码安全性会丢失。 […]