是否可以将多个NSUndoManagers与一个Core-Data managedObjectContext一起使用？

Question

//编辑:真的,没有人对此有任何建议或想法吗？我是不是错误地问了这个问题？//

我的iPhone应用程序有一个带有中等复杂数据模型的managedObjectContext.我现在正在添加撤消功能,并不清楚如何最好地处理嵌套的viewControllers(因为每个层可能会修改数据模型).

Apple的文档指出:"考虑一个显示书籍列表的应用程序,并允许您导航到详细视图,进而允许您编辑书籍的各个属性(例如其标题,作者和版权日期).您可以从列表屏幕创建一本新书,在两个其他屏幕之间导航以编辑其属性,然后导航回原始列表.如果列表视图中的撤消操作未对作者姓名进行更改,则可能看起来很奇怪两个屏幕,而不是删除整本书."

---

那么实现这个的最佳方法是什么？目前,我正在考虑让每个viewController保留自己的undoManager,只要它在屏幕上,它就会处于活动状态.所以我的理解是这需要以下步骤(对于每个VC):

• 添加属性: myUndoManager
• 添加一个undoManager返回的方法myManagedObjectContext.undoManager;
• 在viewDidAppear: myManagedObjectContext.undoManager = myUndoManager;//首先创建,如果为零
• 在viewWillDisappear:myManagedObjectContext.undoManager = nil;
• 关于记忆警告: [self.undoManager removeAllActions ];
• 关于dealloc: self.myUndoManager = nil;
• 对于每个模型更改: [self.undoManager setActionName:NSLocalizedString(@“XXX”,@“”)];
• CoreData将处理实际的撤消/重做发布

另外,我必须保持第一个响应者:

• 在viewDidAppear:`[self becomeFirstResponder]'
• 添加canBecomeFirstResponder方法返回YES
• 在viewWillDisappear:[self resignFirstResponder];
• 子视图重新签名时重新启用firstResponder(例如textFields)

到目前为止,这似乎是有效的,即使在加载/卸载周期,并且很好地自包含,但我有几个问题:

• 首先,这是跨多个VC实施撤消的最佳实践吗？
• 在我做我之前的那些之前,我的孩子VC没有做他们的动作会遇到麻烦吗？
• 如果是这样,该列表是否会捕获我需要做的所有事情？
• ManagedObjectContext是否会与多个正在运行的UndoManagers混淆？
• 在交换undoManagers之前,是否需要调用ProcessPendingActions？

Answer 1

每个视图控制器都可以有自己的撤消管理器。控制器应该只对其直接更改的字段负责。一旦退出相应的视图，控制器和撤消管理器都应该被释放。

假设您有 3 个级别。级别 1 表示整个记录，级别 2 表示级别 1 中的数据子集，级别 3 表示级别 2 中的数据子集。

一旦您退出第 3 级，您基本上就表示我接受，并且您不需要撤消第 2 级中的任何数据。此更改的数据仅应在第 2 级中显示为只读数据，如果它显示在全部。同样，一旦退出级别 2，您应该释放其撤消管理器。

回到第 1 级，因为它代表整个记录，为什么不使用“取消”按钮而不是尝试撤消（或除此之外，取决于您的第 1 级控制器的功能）？

然后，如果您想取消整个操作，您可以向托管对象上下文发送如下消息：

[myMOC refreshObject:theEditedObject mergeChanges:NO];

这将有效地回滚整个记录。

如果出于某种原因，您决定在处于第 2 级时保留第 3 级的撤消管理器，并且在第 2 级执行回滚，则只会回滚与第 2 级撤消管理器相关的数据。级别 3 的撤消管理器是独立的，并且 Core Data 不会将撤消管理器视为嵌套的。

托管对象上下文不会因多个撤消管理器而混淆，因为它一次只能通过其setUndoManager:方法跟踪一个撤消管理器。

您可能不需要使用processPendingChanges，除非在更改后事件循环完成之前以某种方式发生回滚。我不会担心这个，除非您的撤消仅恢复了到目前为止应该由撤消管理器记录的一些数据。