代码之家  ›  专栏  ›  技术社区  ›  Bjorn

如何在没有接口生成器的情况下创建Cocoa接口?

  •  38
  • Bjorn  · 技术社区  · 15 年前

    我更喜欢用编程方式创建接口。似乎苹果开发人员的所有文档都假设您使用的是Interface Builder。是否可以通过编程创建这些接口,如果可以,我从哪里开始学习如何创建这些接口?

    我认为这方面的相关文件(如果可能)将在本节中: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html

    5 回复  |  直到 7 年前
        1
  •  23
  •   Peter Hosey    15 年前

    我更喜欢用编程方式创建接口。

    为什么?界面生成器越来越简单和快速。你不能通过拖拽来写一个打字错误,而且当你用手打字矩形的时候,你不会得到那些非常方便的水上指南。

    别打了。界面生成器是您的朋友。让它帮助你。

    如果你 坚持 通过编写代码来浪费自己的时间和精力:

    不基于文档(通常基于库,如mail、itunes、iphoto):创建nsObject的子类,将其实例化,并使其成为应用程序的委托,以及在委托的 applicationDidFinishLaunching: 方法,创建一个窗口,用视图填充它,并将其排在前面。

    基于文档(如文本编辑、预览、QuickTime播放器):在 makeWindowControllers 方法,在nsdocument的子类中,创建窗口(并用视图填充它们)并为它们创建窗口控制器,确保自己发送 addWindowController: 对于每个窗口控制器。

        2
  •  36
  •   Conal    11 年前

    我喜欢这个问题,我还想知道减少ib的资源。有用性(“为什么”)仅受想象力的限制。在我的头脑中,有一些可能的原因可以明确地对uis进行编程:

    • 实现更好的接口生成器。
    • 编程动态uis,即结构不可静态知道的uis(在编译/xcode时)。
    • 为uis实现跨平台库或语言的cocoa后端。

    上有一系列的博客文章 working without a nib a recent description by Michael Mucha on cocoa-dev .

        3
  •  19
  •   Everett Zufelt    14 年前

    作为一个完全盲开发人员,我可以说ib与Voiceover(OS X上的内置屏幕阅读器)不兼容。

    这意味着,在没有ib的情况下,如果无法访问有关使用cocoa的强大文档,我就无法在cococo中开发OS X/iPhone应用程序,这意味着我(具有讽刺意味的是)无法轻松开发盲人(以及所有其他人)可以在OS X/iOS上访问的应用程序。

    我目前不想使用的解决方案是Java+SWT,当然,这对于OS X来说是有效的,而不是IOS。

        4
  •  4
  •   Paulo    14 年前

    事实上,当您开始编写自己的UI类时,ib变得完全无用。假设您创建自己的按钮,使用基于plist的皮肤系统。或者创建一个常规工具栏,根据用户选择加载和卸载项目。

    ib不接受自定义的ui元素,所以更复杂的ui不能使用它。是的,你会想做uikit给你的更复杂的事情。

        5
  •  3
  •   Community rohancragg    7 年前

    虽然这有点老… 我试过很多次,都是用程序来完成的。这很难,但可能。

    更新 : 我发表了另一个关于这个特定问题的问题: View-based NSOutlineView without NIB? 现在 我相信每件事都可以用程序化的方式完成,但是由于缺乏信息或例子,没有苹果工程师的咨询是非常困难的。


    下面的论点可能是离题的,但我想指出为什么我强烈喜欢编程方式。

    我也喜欢程序化的方式。因为

    • 静态布局工具无法处理任何动态内容。
    • 在多个笔尖上复制相同的用户界面状态是困难的。一切都是含蓄的或隐藏的。您需要访问所有面板 找到 参数。这种工作很容易出错,容易出错。
    • 管理一致状态是困难的。因为复制相同的外观是困难的。
    • 不可能实现自动化。不能生成自动生成的输入窗体。
    • 参数间接(例如用户选择的可变元素大小)是不可能的。
    • 瞄准小点比在固定位置按手指大小的键要困难得多——有趣的是,这对开发人员来说是一个严重的可用性问题!
    • 有时是螺钉。这意味着它是可编译的,并且仍在工作,但是当我打开源代码时,它看起来已经坏了,无法进行额外的编辑。(您可能还没有体验到这一点,但如果XIB文件变得复杂,则一定会发生这种情况)
    • 它是基于图像的序列化。概念不错。但问题是图像基础 只有 . ib不会通过重放源代码来保持源代码的干净引导。清洁引导对于保证特定的运行状态非常重要。此外,我们无法修复源代码中的错误。bug s将被无限地堆积。这就是我们不能复制 平等的 (外观不相似)ib中的ui状态。

    当然,这些东西可以通过后处理NIB用户界面来解决,但是如果我们必须配置所有东西的话 再一次 一开始没有理由使用ib。

    使用文本代码,很容易复制相同的状态—只需复制代码即可。也容易检查和修复错误的部分-因为我们完全控制。但在ib中,我们无法控制核心细节。

    ib不能是最终的解决方案。它就像一个photoshop,但即使是photoshop也提供了基于文本的脚本功能。图形用户界面是一个移动程序,而不是静态图像或图形。即使对于图形用户界面的可视化编辑,ib方法也是完全错误的。如果你是阅读本文的苹果人之一,我请求你尽快完全消除对ib的依赖。