3

作为 ios 编程的新手，
我当然是从故事板开始的，然后我读到当多个开发人员在同一个应用程序上工作时它有其局限性，所以我切换到纯代码。但我想 xib / nib 可能是一个很好的折衷方案。
你能给我一个更成熟的观点吗？

非常感谢你的灯

4

3 回答 3

8

我会投票反对使用故事板。它们就像通常的眼睛糖果一样，在 WWDC 演示文稿中看起来很漂亮，但在现实生活中它很少做正确的事情......故事板迫使你做出不幸的架构决策（见：http:// do-it-wrong.mikeweller.com/2013/06/ios-app-architecture-and-tdd-1.html），随着您的项目的进行，故事板迅速演变成可怕的视图控制器和segues，而不是提到合并故事板的问题......去过那里，做到了。用 vim。那是痛苦的……

事实上，我已经在一个项目上工作了 6 个月，开始使用故事板，现在开发到了我考虑（如果截止日期不会接近）将整个东西分成单独的 XIB 的地步，如果不是纯代码。

只有在以下情况下，您才应该使用故事板：

  • 你正在做概念验证应用程序/原型
  • 您计划使用不超过 6 个视图控制器
  • 您将使用简单的基于堆栈的导航，并不复杂
于 2013-09-19T21:40:25.180 回答
5

我仍然建议使用情节提要……如果需要，每个项目可以有多个情节提要，它们确实可以减少创建 UI 所需的时间。此外，如果你擅长 git，在大多数情况下你可以很容易地解决冲突：http: //blog.mugunthkumar.com/articles/avoiding-merge-conflicts-with-storyboards/

至于对 UI 进行编码，有几件事最好在代码中完成……但是以编程方式构建整个 UI 就像在可以使用铲子时尝试用勺子挖一个洞一样。

于 2013-09-19T21:24:41.230 回答
1

除非您使用多个故事板，否则使用故事板可防止两个或多个开发人员同时处理不同的视图。

使用 .xib 文件，每个视图控制器一个允许一个开发人员使用 FirstViewController 及其关联的 .xib 文件，而另一个开发人员则使用 SecondViewController 及其关联的 .xib。这样，不同开发人员所做的事情就没有重叠，并且一个开发人员的更改不会抹杀另一个开发人员的更改。

于 2013-09-19T20:37:21.710 回答