问题标签 [cocoa-design-patterns]

我是一位经验丰富的开发人员，不熟悉 Mac 开发，所以我

• 阅读一份不错的 Objective C 指南
• 阅读Apple 内存管理指南
• 浏览了Apple 对 Cocoa 的介绍
• 检查了NSApplication和NSApplicationDelegate Refs
• 有点乱

仍然有很多差距，我很难找到好的可读性。下面列出了我的一些问题。这些非常简单/通用。必须有一个简短的文档，详细说明基本的应用程序引导过程以及所有涉及的类。谢谢！

• XCode 生成的“委托”包含 NSPersistentStoreCoordinator、NSManagedObjectModel 和 NSManagedObjectContext 的实例——请详细说明？
• 委托被声明为 "@interface tests_AppDelegate : NSObject {" 。为什么缺少协议？我在那里看到了网上的例子。
• 我看到应用程序委托是在 Interface Builder 中实例化的。它在哪里传递到 NSApplication 实例？

我目前正在为我正在尝试创建的文档制定最佳结构。该文档基本上是使用 sqlite 作为其存储的核心数据文档，但使用 Apple 提供的 NSPersistentDocument+FileWrapperSupport 来启用文件包装器支持。

该文档大量使用媒体，例如图像、视频、音频文件等，可能包含 1000 多个文件。所以我想做的是创建一个类似于以下的结构：

现在，首先我创建了一个临时目录并将我的所有媒体都放在那里。基本上创建路径和文件名'/content/images/image1.jpg'，因为我希望它们出现在保存的文件包装器中，然后在保存时我试图将这些全部复制到文件包装器中......

我发现这些文件确实以我想要的文件结构复制到了包装器中，但是当实际的包装器被保存时，这些文件都神奇地消失了。

伟大的。

所以，我废弃了我现有的解决方案并尝试使用文件包装器。该解决方案涉及在创建新文档时创建内容包装文件目录，或在打开文档时加载内容目录文件包装。

添加/修改图像时，我在此根内容包装器中创建了必要的目录包装器（即图像目录包装器，如果它不存在，或任何其他需要创建的中间目录包装器），然后创建一个常规媒体的文件包装器，删除该文件名的任何现有包装器（如果存在）。

保存文档只是确保将内容文件包装器添加到文档文件包装器的情况，并且文档将保存。

嗯……确实如此。第一次。但是，任何尝试进行任何后续更改，即添加图像，保存。然后替换图像，保存。未按预期运行，仅显示第一次保存的图像。

所以，我的问题是......首先，上述哪种方法是正确的，如果有的话，我做错了什么让他们失败。

其次，正如我期望管理 1000 张图像一样，使用文件包装器是处理事情的正确方式。

我正在制作一个自定义视图，我希望它与绑定/核心数据兼容并表示数据集合（a la NSTableView）

在用户更改后，我的视图是否可以引用集合中元素的特定子集（当前选择除外）？

一点上下文：
该视图将在 2D 空间中显示许多用户可移动的框。每个框对应于模型中的一条记录。几个可以一次移动，我不能依赖每个框的 delta 值相同（所以不要向每个选定的对象添加 delta）。

我想我正在寻找类似于 NSArrayController 为内容数组的每个元素分配的 id，以便视图可以将该 id 与每个框相关联。我的第一个想法是在内容数组中使用索引，但这可能会被撤消/重做弄乱。我可以继承 NSArrayController 并让它为每个模型项自动生成一个 id，但是 cocoa 已经做了这样的事情了吗？感觉我可能错过了什么。

这个约定有什么目的吗？

我希望你能原谅这个问题看似广泛的性质，但它变得非常具体。

我正在构建一个基于文档的 Cocoa 应用程序，它与大多数其他应用程序一样工作，只是我将 SQLCipher 用于我的数据存储（SQLite 的一种变体），因为您无法在 Core Data 中设置自己的持久数据存储，并且我也真的需要使用这个。

在我的文档子类中，我有一个NSMutableArray名为categories. 在文档 nib 中，我NSArrayController绑定了 to categories，并且NSCollectionView绑定了数组控制器。

数组中的每个模型对象（每个都是 a Category）都绑定到底层数据存储中的记录，所以当 Category 的某些属性发生变化时，我想调用[category save]，当 Category 添加到集合中时，我想再次调用 ，[category save]最后，当一个类别被删除时，[category destroy]。

我已经建立了一个部分解决方案，但它在移除要求上分崩离析，在我看来，关于它的一切似乎都在吠叫错误的树。无论如何，这就是发生的事情：

一旦文档和笔尖都加载完毕，我开始观察类别属性，并为其分配一些数据：

我以这样一种方式实现了观察方法，即通知我更改，以便文档可以响应和更新数据存储。

正如您从该列表中看到的（并且您可能已经知道），仅观察属性是不够的categories，我需要观察每个单独的类别，以便在其属性发生更改时通知文档（如名称）所以我可以立即保存更改：

这在我看来就像一个大杂烩，我怀疑我在这里与 Cocoa 对抗，但在大多数情况下它是有效的。

除了删除。当您向界面添加一个按钮并将其分配给数组控制器的remove:操作时，它将正确地从categories我的文档的属性中删除该类别。

这样做时，该类别在仍处于观察状态时被解除分配：

此外，由于在我收到通知之前对象已经被释放，我没有机会[category destroy]从我的观察者那里调用。

一个人应该如何正确地与 NSArrayController 集成以保持对数据模型 pre-Core Data 的更改？如何解决这里的删除问题（或者这完全是错误的方法？）

提前感谢您的任何建议！

StackOverflow 的好人，

我正处于构建非基于文档的 Cocoa 应用程序的早期阶段。我的目标是类似于 iTunes 的窗口布局，具有左、中和右窗格。此类应用程序的 Xcode 模板包括一个名为 MainMenu.xib 的文件，其中包含主菜单和主应用程序窗口，支持逻辑包含在 MyApp_AppDelegate 类中。

我已经可以预见，沿着这条路线继续下去最终会导致一个非常庞大且杂乱无章的应用程序委托类。因此，我的蜘蛛侠感觉告诉我将主窗口的逻辑分解为它自己的 NSWindowController 子类（以及随附的 XIB 文件）。此外，将每个窗格拆分为自己的 NSViewController 子类是否正确？这似乎更好地分离了我的关注点，但代价是更多的文件和一些额外的代码将所有东西连接在一起。

我能找到的最接近的建议是在 Apple 的Interface Builder User Guide中，但它没有直接回答这个问题。但是，我想我的问题不是特别关于 nib 文件，而是关于高级应用程序组织。

Apple 推荐的多线程核心数据方法是为每个线程使用一个托管对象上下文，并通过将更改的线程的上下文保存到共享持久存储来将更改从一个上下文发送到另一个上下文。

虽然我可以想象这对例如很好。一个 RSS 阅读器，对于某些应用程序来说，它似乎远非理想。就我而言，我正在编写一个使用后台线程记录和播放数据的音乐音序器。我需要在录制/播放期间主线程可以访问录制的数据。在录制/播放时必须不断地保存和加载数据已经够糟糕了，但更糟糕的是，它似乎会迫使用户在录制或播放时进行保存，这有点尖叫“糟糕的应用程序”。

但是，似乎有一种方法可以回避这一点。如果其他线程不需要访问核心数据实体本身（只是它们包含的数据），那么阻止我在自己的线程中运行托管对象上下文，并且只允许其他线程间接访问，例如通过绑定 UI对象到调用performSelector:onThread:withObject:waitUntilDone:托管对象上下文的线程以获取/设置值的属性？

它没有提供多线程的一些好处（即，将核心数据扩展到多核 CPU），但很多时候，我们只是希望多线程避免在发生密集事件时锁定 UI。

我还没有看到这种模式提倡核心数据。考虑到当你不完全按照苹果的建议去做时，它可能是一个奇怪且不可预测的野兽，我认为这是否真的避免了我们不鼓励让多个线程访问单个托管对象上下文的原因是值得的.

我有一个简单的查询，我想被某人清除……保留自我是不好的做法吗？

我有一个我想做的服务器请求对象。我希望能够以下列方式使用它：

为了使对象在自动释放池耗尽后不会自毁，我想我需要在它的 init 方法中调用一个保留，然后在服务器响应被接收、处理并交付给它的委托后释放。

但是，这种方法在我脑海中敲响了警钟。更好的方法来做到这一点？

我的视图改变了大小，我有工具提示的相关图形元素已经改变了位置。我真的必须删除每个工具提示并使用新的矩形再次添加吗？或者某处是否有一些“modifyToolTipRect”。我找不到一个。

我有一种情况，我在基于文档的应用程序中有多层嵌套对象，需要了解有关某个模型的信息。

具体来说，我有一个 NSTextView、NSLayoutManager 和 NSTypesetter，它们中的每一个都需要知道关于我的文档模型的某些属性才能正确呈现它。

目前，我已经对每个类进行了子类化，并为它们提供了一个引用我的模型的属性。引用从我的文档控制器传递到子类 NSLayoutManager，然后传递给子类 NSTypesetter：

模型是从 Controller->MyLayoutManager->MyTypesetter 传递过来的。这似乎有点多余，而且可能耦合得太紧了。

委托模式会更好吗？如果是这样，最好的设置方法是什么？Typesetter 没有委托，但 LayoutManager 已经有委托。是否应该向 Typesetter 添加一个委托，然后覆盖 LayoutManager 上的委托？还是坚持传递我的模型界面会更好？

任何见解将不胜感激。谢谢。