iOS 4 应用程序终止和撤消

发布于 2024-09-14 19:23:12 字数 706 浏览 7 评论 0原文

使用 NSUndoManager 时处理 iOS 4 应用程序终止的好方法是什么?

我有一个使用 Core Data 的 iPhone (iOS 4) 应用程序。该应用程序允许用户编辑托管对象,并且我以简单的方式使用 NSUndoManager 实现撤消:在模态显示编辑器视图之前,我为托管对象创建一个新的 NSUndoManager对象上下文。我还开始撤消分组,以便在用户点击“取消”按钮时可以轻松撤消任何更改。如果用户点击“保存”,我只需删除撤消管理器,更改就会永久生效。到目前为止,一切都很好。

如果用户在编辑对象的过程中按下主页按钮(或接听电话),应用程序将被挂起。它向应用程序委托发送一条 applicationDidEnterBackground 消息,我利用这个机会保存托管对象上下文。当然,上下文包含新的编辑,只是等待 NSUndoManager 撤消。

问题是:如果应用程序稍后“取消挂起”,NSUndoManager 仍然存在并且一切正常。但是,如果应用程序被操作系统“在睡眠中杀死”,则撤消堆栈将丢失,并且对对象所做的更改现在将成为永久性的。重新启动时,我想将应用程序恢复到与暂停之前完全相同的状态,但这似乎需要我保存并恢复撤消堆栈。不幸的是,我找不到明显的方法来做到这一点。

有没有一种好方法来支持撤消,以便无论应用程序是否终止,它都可以一致地工作?我希望我遗漏了一些明显的东西。任何帮助或建议将不胜感激。

What is a good way to handle iOS 4 app termination when using an NSUndoManager?

I have an iPhone (iOS 4) application that uses Core Data. The app allows the user to edit managed objects, and I implement undo using NSUndoManager in a straightforward manner: Before displaying an editor view modally, I create a new NSUndoManager for the managed object context. I also begin undo grouping so that any changes can easily be undone if the user taps the "Cancel" button. If the user taps "Save," I simply remove the undo manager and the changes become permanent. So far, so good.

If the user presses the Home button (or takes a call) in the midst of editing an object, the app gets suspended. It sends the app delegate an applicationDidEnterBackground message and I use that opportunity to save the managed object context. The context, of course, contains the new edits, just waiting to be undone by the NSUndoManager.

Here's the issue: If the app is later "unsuspended," the NSUndoManager still exists and everything works fine. However, if the app gets "killed in its sleep" by the OS, the undo stack is lost and the changes made to the object now become permanent. At relaunch I want to restore the app to the exact same state it was in before it was suspended, but that seems to require me to save and restore the undo stack. Unfortunately, I couldn't find an obvious way to do that.

Is there a good way to support undo so that it works consistently whether or not an app is terminated? I hope I'm missing something obvious. Any help or suggestions would be appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

凤舞天涯 2024-09-21 19:23:12

您可以花费世界上所有的时间将当前的应用程序状态序列化到磁盘,以便您可以从上次中断的地方重新启动……

或者您可以通过减少内存占用来回避问题,这样您就不太可能被杀死在后台时。我怀疑由于电话而后台运行的应用程序比其他后台应用程序具有更高的优先级,即使只是因为它最近使用过。

内存不足、更新应用程序或点击任务切换器中的框都可能杀死您的应用程序。由您决定是否需要保留应用程序所处的准确状态。我认为 Android 只会将序列化的应用程序状态保留大约 30 分钟,因为短期记忆往往不会持续时间更长。

(什么?.foo.txt.swp 存在?已经有几个月了!我怎么知道它来自哪里?为什么你不能直接向我显示它与 foo.txt 之间的变化,以便我可以决定是否要保留它吗?)

You can spend all the time in the world serializing your current app state to disk so you can relaunch where you left off...

... or you can sidestep the issue by reducing your memory footprint so you're less likely to be killed while in the background. I suspect the backgrounded-due-to-phonecall app is given priority over other background apps, if only because it is more recently used.

Low memory, updating the app, or tapping the box in the task switcher can all kill your app. It's up to you to decide whether you need to preserve the exact state the app was in. I think Android only preserves the serialized app state for about 30 minutes, because short-term memories don't tend to last much longer.

(What? .foo.txt.swp exists? It's several months old! How am I supposed to know where it's from? Why can't you just show me the changes between that and foo.txt so I can decide whether I want to keep it?)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文