When I restart the device my app is on it won't preserve the state it had once I open up the app again, it will be as if it's the first time I open, losing the session and having to re-login, how can I make my app preserve its state even through a device reboot? Like Twitter does, for example.
I'll try a bit more formal answer based on the comments you added above. I'll start by saying that the link Tim posted is something you should familiarize yourself with.
When your app is running, it's in the Foreground state. When you "exit" an app with the Home button, you're not really quitting it; you're just pushing it to the Background state. after a few seconds in background state, the OS automatically moves the app to the Suspended state. If you come back within a few minutes, your app is still in memory, so the OS just puts it back on the screen the way it was.
However, if you leave the app alone for a while and use other apps, the OS can--at any time and without warning--purge your app from memory. This is known as the "Not Running" state. Now, when the open the app again, it has to start from scratch. Obviously, the same thing happens when the device restarts--all apps are purged from memory.
The trick, then, is to save essential information about the app state whenever it enters the background state. You can use the app delegate's didEnterBackground method, or register for the UIApplicationDidEnterBackgroundNotification and invoke a method in your active view controller (or any other class, for that matter). Either way, you should save whatever state information you can.
How do you save this information? There are several strategies. For a simple app, perhaps you can register a few setting as NSUserDefaults. Or maybe you can write out a file containing whatever data the user was working on. It's really up to you.
Then, whenever the app launches, check for the presence of that saved data (however you chose to write it out), and set up the UI accordingly. To the user, it will appear as though the app never quit, which is exactly what Apple wants them to think.
Related
I have a CLLocationManager contained in a singleton and I have added around a dozen regions to monitor. I am successfully notified of boundary crossings when the app is in the foreground/background. However, when I force quit the app, the location icon disappears and I am not getting any callbacks.
As far as I can see, this is intended functionality as of iOS7. Here is a reply I found to a similar question, in this case involving significant location change: https://devforums.apple.com/message/882691#882691:
If a user swipes up in the app switcher then the OS will not launch the app unless explicitly told to do so by the user. So no, SLC will not be launching the app, nor will silent notifications. The only thing that will launch the app at that point is the user tapping the icon. The intention here is that the user has expressed their choice of not having that app running any more for any reason, so we honor that.
In this situation, there's really nothing that you can do. The next time the user launches the app you can let them know that some of the data may be missing, although you really cannot tell whether there's missing data or not (i.e. you might have been killed by the OS in the background and the user may not have moved thereby not triggering any SLC notifications). My suggestion would be to gather the data you can within the policies of the OS and if the user has manually killed the app then respect that wish and don't do anything.
By all means, feel free to file a bug report if this change in behavior winds up causing problems for you or (especially) confusion for your users.
I am running my iPod touch application and then go in background and change the device language from Settings application and try to bring that application on foreground. My application gets restarted and I do not land on the screen where I left the application when I went into the background.
Is this because a KILL signal is sent by settings application when language was changed? Is it the desired behavior?
I wasn't aware the switching the language would cause apps to be terminated, but that's not shocking. It's a very straightforward way to get what the user wants. Your problem isn't the language change, though. The problem is that you're not responding correctly to a notification of termination. You can be terminated at any time when you're in the background, and it's your job to deal with it.
Your application delegate should implement applicationWillTerminate: (or you can observe UIApplicationWillTerminateNotification wherever it is convenient). When you receive this, you should save off sufficient information to get yourself back to where you were when you restart. As much as possible, you should make it look to the user that you did not terminate. The easiest place to save state is usually in NSUserDefaults, but you can use any mechanism you like.
Handling application restart is one of those things that separates excellent iOS applications from "good enough."
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.
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?)
My application uses NSUserDefaults to store some values so that it can restore them on application update or if backgrounding is quit. Backgrounding automatically saves my integer values, but if the user quits the application from the launcher, the numbers are lost too, and the ViewDidUnload method I guess doesn't evoke when entering backgrounding. Is there a way that I can save the NSUserDefaults any time the application unloads. Also, the ViewDidLoad method had the same problem, it doesn't evoke from backgrounding. What's a way around this?
P.S. So far the only data my application needs to save is an int for an on-screen count.
UPDATE: UIApplicationDidEnterBackgroundingNotification works great with your suggestions!
You can't save data right before it eventually gets killed, but you can save state 'just in case' in your applicationDidEnterBackground: app delegate.
There's also applicationDidBecomeActive:, but there's no reason to load your save data from there, since when it's invoked from an app that was in the background, the data will have been preserved any way.
You can't tell if your app was launched from the background or not, at least how it's currently set up, since your app delegate will get the same sequence of events if it's launched from springboard.
As Joost says, you should save anything you need to restore state inside the applicationDidEnterBackground callback; essentially, you should assume this is the last message your app will get before it gets killed mercilessly by an evil process reaper.
You should check out the WWDC 2010 Session Videos, specifically, Session 105 - Adopting Multitasking on iPhone OS, Part 1 for a thorough explanation.
I am fairly new to iphone app development. I am creating an app that has multiple views. Initially it starts with a view for authentication and then load views according to user interaction. When I build and run the app - the first time it shows the "Default.png" screen and then shows the first view where I do my authentication process (typing in userid,password and do a web service) and then after the credentials are verified it takes me to the next view. When I close the app at this state in the simulator and reopen it again, I am seeing the same state in which I closed my app. But here is what I want. When I relaunch the app I should be able to show the "DEfault.png" and screen and then show my initial authentication view. Can you please help me out on this ? Thanks
It sounds like the problem you are trying to solve is that your authenticated session may time out while the app is suspended and you need to log in again.
Although the proposed solution (setting UIApplicationExistsOnSuspend to true) would work I think you should consider a different approach.
Apple recommends that you do everything you can to make it look like the phone supports multitasking. That is why, by default, your app will suspend and resume instead of exit and relaunch. In your case, though, you may need to re-login to resume the session. I offer you a couple of alternate solutions:
Cache the credentials (ie username and password) and silently use them to resume the session when needed. If the back-end supports this.
Detect when the session has become stale and bring in a view to inform the user that the session has expired and ask them to log in again. This would also address the issue if the user keeps the app active past the timeout of the session.
Both of these approaches should improve perceived app performance and integrate better into the Apple usability guidelines.
That's because iOS 4 apps are supposed to support multitasking. You can change the app so it doesn't: In Info.plist, set UIApplicationExitsOnSuspend to true (i.e. <key> UIApplicationExitsOnSuspend</key><true/>) — make sure it's a boolean and not a string. Note that this will probably make startup slower, since the app has to be launched again.
The other way is to handle applicationDidEnterBackground: in your app delegate and do two things:
Reset your view hierarchy (you can do this on next launch, but doing it earlier might help to free more memory)
Show "Default.png" in a full-screen view — iOS takes a screenshot of your app after it's hidden which it uses to animate the app back in.