在 iPhone 上使用模态视图控制器编辑属性时应使用哪种模式？

Question

我正在寻找一种通过 iPhone 上的模态视图执行基本属性编辑的良好模式。

假设我正在构建一个与“联系人”应用程序类似的应用程序。 “详细信息”视图控制器在 UITableView 中显示联系人的所有属性。当 UITableView 进入编辑模式时，单元格中会显示一个公开图标。单击单元格会导致模式“编辑器”视图控制器显示允许用户修改所选属性的视图。此视图通常仅包含一个文本框或选择器。用户单击“取消/保存”，“编辑器”视图将被关闭，“详细信息”视图将被更新。

在这种情况下，哪个视图负责更新模型？

“编辑器”视图可以使用键值编码直接更新属性。这出现在 CoreDataBooks 示例中。这在某种程度上对我来说是有意义的，因为它将属性视为编辑器视图控制器的模型。

然而，这不是视图控制器编程指南建议的模式。它建议“编辑器”视图控制器应该定义“详细信息”控制器采用的协议。当用户指示他们完成编辑时，将使用输入的值回调“详细信息”视图控制器，并关闭“编辑器”视图。使用这种方法，“详细”控制器更新模型。如果您对多个属性使用相同的“编辑器”视图，则这种方法似乎有问题，因为只有一个回调方法。

希望获得一些有关哪种方法最有效的反馈。

Answer 1

我不认为任何 Apple 示例（或其他任何人的示例）实际上向您展示了如何构建整个现实世界的应用程序。相反，每个示例只是一个测试工具，它向您展示如何使用 API 的一项特定功能，但不关注该功能如何与其他功能真正集成。数据模型的转变特别短。

我更喜欢这样的设计，其中数据模型是应用程序的主干，所有视图控制器/视图对都由它负责。视图控制器不直接相互通信，而是通过数据模型进行通信。数据模型跟踪应用程序当前正在处理哪些信息，以及每个特定视图控制器在任何给定时间需要哪些数据。

让我们以联系人管理器类型的应用程序为例。数据模型的基础是联系人对象的列表，每个对象又包含联系人的属性。数据模型将完全控制对数据的访问并监视当前正在使用哪些数据。 UI 是分层的，用户首先在 masterView 中看到所有联系人的列表，然后在 contactDetailView 中看到每个联系人的详细信息，然后可以在自定义属性编辑视图中为每种类型的数据编辑每个联系人属性，因此有一个nameEditView、phoneDetailView、emailEditView 等。每个都有一个配对的视图控制器 masterVC、contactDetailVC、nameEditVC 等。

为了构建它的表视图，masterVC 向数据模型询问联系人的数量、它们的划分，然后请求每个特定的联系人每个特定索引路径上的对象，以便它可以显示一个表。当用户选择表行时，masterVC 通过向数据模型发送索引来告知数据模型选择了哪个联系人对象。然后masterVC推送contactDetailVC。它没有任何其他作用。

当 contactDetailVC 激活时，它会向数据模型询问当前活动的 Contact 对象。它不知道也不关心当前联系人是如何选择的，甚至也不知道它之前是哪个视图/VC。数据模型返回当前活动的联系人。当用户选择一个字段时，contactDetailVC 告诉数据模型选择了联系人的哪个属性，然后将适当的 editorVC 推送到堆栈上。

当 editorVC 加载时，它会询问当前联系人和当前正在编辑的属性的数据模型。它不知道也不关心当前联系人属性是如何选择的，甚至也不知道它之前是哪个视图/VC。当用户进行更改时，它会要求数据模型保存更改（如果由于某种原因验证失败，数据模型可以拒绝），然后自行弹出。

在内部，我喜欢将数据模型分为两个部分，每个部分由单独的对象管理。一个是抽象数据管理器本身，在本例中是核心数据堆栈。第二个是用户默认值管理器，用于跟踪数据模型中的实际操作状态并将其保存到用户默认值。主对象将这些对象作为属性保存并充当数据模型的接口。

这种类型的模型可以轻松地暂停、恢复或重新启动应用程序回到之前的状态。由于每个视图/VC 都是独立的，因此当您重新启动应用程序时，您只需将所有视图推送到堆栈上而无需动画，最后一个推送的视图会完全填充数据，即使用户在之前的视图中没有选择任何内容并且确实这样做了甚至看不到他们。

它还可以保护用户在崩溃时避免数据丢失，因为每个 VC 每次推送或弹出时都会保存其数据和应用程序状态。添加额外的视图/VC 很容易，因为每个 VC 只需了解数据模型并与之通信，而不需要一堆其他 VC。它使应用程序的组件易于在不同版本的应用程序或完全不同的应用程序中使用。

编辑：

你只是硬编码一些 if
配对属性的语句
使用正确的编辑器，或者您是
做一些更有活力的事情
实体/属性元数据？

在大多数最常见的设计中，联系人实体可以具有可变数量的电话号码、电子邮件或其他数据字段，因此每个属性实际上都是一个单独的实体，并且联系人将具有指向这些实体的关系。当用户在 ContactDetailView 中选择要编辑的联系人时，数据模型将简单地标记代表联系人所需属性的 NSManagedObject。它可以通过设置“lastChosenAttribute”之类的属性或存储对象的 URI 来实现此目的。当编辑器视图加载时，它将被硬编码以向数据模型询问“lastChosenAttribute”，并会收到电话号码、电子邮件等的 NSManagedObject。编辑器将对该对象进行更改，并且它们将自动保存回联系方式。

对于单一数据，例如名称或名称组件，数据模型将为 editorVC 提供联系人实体，并且 editorVC 将被硬编码以向联系人对象询问该特定属性。

Answer 2

这是一个艰难的决定——视图控制器指南建议在概念上似乎更清晰，但其他方法可能更容易，特别是当您使用核心数据时。为了给出一个笼统的概括意见，如果您使用 Core Data，我会说使用您的第一种方法，因为托管对象本质上有自己的上下文并且可以更新自己（并且诸如 NSFetchedResultsController 之类的类可以自动响应更新）。

如果您不使用核心数据，我会采用“官方”建议，因为它可以更轻松地手动管理更新的属性。至于对多个属性的关注，当然可以有多个委托方法并调用适当的方法。例如：

//if property is an address
if ([self.delegate respondsToSelector:@selector(editorView:didUpdateAddress:)])
    [self.delegate editorView:self didUpdateAddress:theAddress];

//if property is a name
if ([self.delegate respondsToSelector:@selector(editorView:didUpdateName:)])
    [self.delegate editorView:self didUpdateName:theName];

不过，这可能很难管理——您可能希望有一个属性的抽象超类，或者类似的东西。