代码之家  ›  专栏  ›  技术社区  ›  Jacob Relkin

用nib或代码设计iPhone界面?

  •  15
  • Jacob Relkin  · 技术社区  · 16 年前

    我思考这个问题已经有一段时间了。。。

    如有任何建议,将不胜感激。

    4 回复  |  直到 14 年前
        1
  •  17
  •   Bryan Henry    16 年前

    我曾经强烈反对在自己的项目中使用Interface Builder。这是由许多因素造成的。我第一次使用Xcode工具是在iPhoneSDK回到beta版(大约2008年3月)时开始的,因为我不是MacCocoa背景,所以我对使用它有点不熟悉。这并不是我最初拒绝IB用于iPhone开发的主要原因,不过,在最初的iPhone SDK测试期间,iPhone开发的界面生成器确实很糟糕,使用起来很痛苦。

    然而,与今天的iphonesdk相比,情况大不相同。虽然仍然存在一些恼人的IB bug,但我对使用Interface Builder的态度已经做了将近180次了。我发现,在项目中使用Interface Builder通常是个好主意。这是一个伟大的工具,现在,你应该利用它自己。

    现在,不要误会我的意思——我仍然坚定地站在相信你应该能够实施的阵营中 任何东西 您可以在Interface Builder中单独使用代码,我认为能够这样做是非常宝贵的。不要把Interface Builder当作拐杖——最终只会伤害你自己(以及你的生产力或产品质量)。虽然IB的拖放细节对于您需要做的90%的事情来说是非常好的,但是当您有一些自定义的东西要实现,而这些东西只能在代码中完成时,您可能希望您遵循了这些建议,或者感谢您遵循了这些建议。幸运的是,我恨IB的时间足够长了,我自学了如何在代码中独立完成所有事情,然后将这些知识应用到IB中。

    编辑:
    为了解决NIB与代码之间缺乏可重用性(感知的或真实的)的问题,您不可能实现在Interface Builder中大量重用的东西。您不能在IB中真正创建自定义控件或视图,因此这是不可能的,在大多数情况下,您将实现一个视图控制器子类,该子类是为满足特定目的而构建的。当然,您应该始终努力使代码和相关资源尽可能可重用。这可能包括设计注意事项,以确保不会不必要地复制非常相似的视图控制器子类。

        2
  •  8
  •   jsoverson    16 年前

    使用构建器可以使您从原本需要维护的代码中解放出来,而且维护的代码越少越好。

    IB构建的布局确实需要一些维护,但它是一个标准工具,有自己的文档和在线支持(论坛、列表等)。如果其他人需要跳入您的代码,您可以保证他们有IB方面的经验,但不一定是您特定的布局构建风格。

        3
  •  7
  •   justin    13 年前

    这取决于你的喜好。

    我更喜欢用代码来写。

    1. 我可以重用代码。
    2. 使用XIB/NIB通常会打破一个定义规则(如果您正在进行任何自定义)。
    3. XIB/NIB维护通常更加繁琐且容易出错(ODR)。我真的不喜欢为每个按钮维护按钮样式(示例)。
    4. 循环引用更有可能。
    5. 代码/对象/ib实例的可重用性/模块化程度通常较低。虽然我是那种避免ui对象做任何事情的人。
    6. 延迟/不明确的初始化顺序会使客户机处于非常可怕的状态,客户机永远不能假定对象已准备好使用或已完全初始化(除非您更愿意维护这些检查,这是浪费时间的好方法)。
    7. 如果性能很重要,猜猜哪个更快?

    如果您有任何维护或重用它的意图,那么您认为在原型存在之后,用代码编写它是最容易的。

    我的建议是:编写高度可重用和稳定的代码库,并将IB主要用于原型设计和一次性开发。


    响应:

    Sbrocket:我很好奇为什么你断言循环引用更可能是使用nib的结果。

    缺乏可靠的结构化所有权、标识和初始化。我不 希望

    回复:吓人

    Nib初始化是半顺序的。实际的顺序/过程可能会有所不同,这无法在可重用的内省程序中可靠地使用。。。同样,您最终会编写太多的代码,这些代码很脆弱,不可能重用,永远无法保证其行为是可预测的,并且必须始终验证状态(循环依赖的另一个条目)。如果它不是一次性的实现,为什么还要为复杂的问题操心呢?

    这种编程方法是混乱的,实现必须(反过来)随时准备好处理任何事情。防止崩溃是一回事,但在这种情况下编写防御性的生产级代码。。。不可能。

    编写一个一致的程序要容易得多,该程序的初始化决定了上下文中的有效性,然后实现就可以知道(如果初始化的话)对象通常已经准备好使用。将特殊情况的复杂性降至最低。随着程序复杂性的增加,许多这样的设计都会分崩离析,而库作者则会一层一层地添加“保护措施”,以保持设备运转——线程是此类海森堡的绝佳入口。在可重用的生产级代码中,不必要的歧义是不受欢迎的;人类不应该交叉引用一个程序的所有特例,与定义的行为和特例有关的复杂性只会传播或被忽略(假设它们被正确地跟踪和记录,这比从一开始就正确地编写要复杂得多)。我想我们都同意应该避免繁重的接口和实现。

    Sbrocket:我也有兴趣看到一些硬性数字表明NIB加载速度较慢——当然,乍一看似乎是有道理的,但如果没有一些硬性测试,我们总是无法预测性能瓶颈。

    我从未(明确地)说过它会慢一些:)

    好吧,严肃地说,NIB取消归档(对我来说)是一个令人惊讶的缓慢过程,尽管我们对缓慢和取消归档时间的看法可能会有很大差异。

    既然您已经有了明确的答案,我将提醒您,您已经拥有衡量性能所需的所有工具。

    请记住,性能分析和增强非常重要 有学问的 .

        4
  •  2
  •   drawnonward    16 年前

    如果你有一个界面,它不会以一种以上的方式使用,有几个但不是很多的元素,并且不需要任何复杂的布局,那么IB是很棒的。