Home/ Questions/Q 1005333
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T08:16:42+00:00

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

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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?)

    • 0