使用界面构建器真的是一个不好的做法?

Gui*_*tro 7 interface-builder ios

我开始在一家新公司开发ios.在这里,他们教我永远不要使用iterface-builder,说它很难维护代码,并且它有一些限制.

在netbeans中使用java应用程序的界面构建我看到很多"坏代码",但我没有看到它使用IB,除了我在互联网上看到很多IB代码,只有少数代码没有它.

对于一个大型的地方,没有人是ios开发的初学者是一个坏的实践使用IB?

小智 18

(我提前提一下,我强烈反对使用Interface Builder,原因有很多,我会解释)

在这里,他们教我永远不要使用Interface Builder,说它很难维护代码,它有一些限制.

这只是部分正确.我不喜欢Interface Builder和Xcode的主要原因是许多初学者程序员认为这是开发iOS/OS X应用程序的唯一方法.他们从来没有听说过的gccclang,他们不知道什么是编译器和链接错误信息的意思是,他们不能使用make,他们有没有什么的Objective-C语言的区别,可可(触摸)API的想法, IDE和编译器是.

毕竟,他们开始使用Interface Builder和Xcode的所有古怪和有时奇怪/不合逻辑的功能(以及错误),但当他们需要开发非显而易见的东西时,他们甚至没有意识到是一种方法,例如,以编程方式创建视图和视图控制器(是的,我在StackOverflow上看到了这个问题).

因此,当被滥用(或者更确切地说,过早使用)时,Interface Builder和所有"方便"的功能会导致程序员学习错误的概念并错过一些重要的实践和经验.

但是,如果您是具有所有必要技能的高级开发人员,并且您认为可以使用简单的文本编辑器和Makefile从头开始编写整个应用程序,那么您无论如何都可以使用IB,如果你觉得比锤击代码更舒服,甚至鼓励这样做.

所以,总结一下:

使用界面构建器真的是一个不好的做法?

不是.滥用它而不是努力学习UI的程序化方法是不好的做法.

Post scriptum:我在iOS开发方面有很多经验,但我仍然发现Interface Builder相当不方便且不一致.我通常使用代码来做所有事情.但这似乎是我个人的偏好.但是,一个优点是,如果一个人通过代码创建所有内容,那么另一个无法访问这些Apple特定工具的程序员也能够为该项目做出贡献.这是"难以维护"部分实现的一点......

例如,直到我没有足够的钱用于Mac,我使用Linux开发iOS应用程序(是的,这实际上是可能的).我无法使用IB和Xcode,但我已经完成了大量的应用程序和调整(当然是越狱的iOS),这很好.

后脚本#2:避免使用IB的另一个原因可能是需要动态UI.如果您非常依赖动画,自定义UI元素等,则很难在Interface Builder中完成所有操作.去年夏天,我不得不重写一个应用程序的登录界面,老实说,如果我不得不使用Interface Builder,我不知道如何实现我们设计师的想法.UI/UX是如此动态,它有很多方法可以改变,因此绝对有必要对每个像素进行精细控制.这就是代码比IB更好的东西.

  • 我不同意"你必须知道关于一切的一切"的论点.但是,我确实同意你必须知道何时使用IB以及何时不使用它.(并且能够这样做).你可以用IB和动态UI做一些强大的功能(比如我用动画画笔提到的iPhoto UI等等),但你显然必须用实际的代码来补充它们.我绝对不认为IB是不好的做法:-) (4认同)
  • 我发现基于代码的视图更流畅,模块化和"域驱动"..当控制器被认为是富模型和丰富视图之间的薄粘合剂时,基于IB的视图倾向于通过提供脂肪控制器来打破MVC..相反,我们有一个厌食症视图和一个胖控制器..使用基于代码的视图,我们可以拥有丰富,可重用的界面. (2认同)

bib*_*ode 7

我强烈不同意IB是一种不好的做法.Interface Builder与代码相比具有以下优势:

  • 当使用复杂(甚至简单)的图形界面时,IB将代码缩减到一小部分 - 例如,简单地在IB中创建按钮需要几秒钟,而在代码中,这会转换为几十行,特别是如果按钮是要设置样式

  • 使用自动调整掩码来支持多种分辨率和设备是轻而易举的 - 这一点非常重要,因为Apple正在推动独立于分辨率的应用程序

  • 更改/调整视图属性只需点击几下而不是代码行,尤其是在处理图像时

然而,有一个缺点(我想到):

  • 很难确定可能导致图形问题的原因,因为它将隐藏在IB文件中而不是代码中