I have a doubt:
I have an app with 10 views. I want that, if the user is on View1 and sends the app to the background, it terminates the application (exit (0)). But I wanted this to happen only on View1, on the other screens, if the app goes to the background and then returns, it will continue where it left off.
What can I do?
Apple's guidelines seem to be strictly against terminating your app programmatically (for example, with exit()); it would go against what iOS users expect of how apps work.
Instead, I recommend the following approach:
When the app is sent to the background (applicationWillResignActive(_:) is called), check which view controller is currently being displayed.
If it's such that you wish to start over next time the app is brought to the foreground, just reset the app window's root view controller to whatever the initial view controller of your app is (typically, it involves reloading the inital view controller from Main.stroyboard, but your setup could be different).
You can not choose at runtime whether your app goes to the background or is terminated when the user presses the home button ("multitasking"); that is set in stone in your Info.plist file at build time.
Also, remember that even if you are in the screen that you wish to preserve when the user resumes, your app might be terminated by the system while it is in the background (to reclaim scarce system resources), so in that case it will still start from the initial screen. To prevent this, you might want to check out the APIs for state preservation and restoration.
Here is another SO question asking how to find the identity of the current view controller. Why not query the current view when you receive applicationWillResignActive indicating that your app is going to move to the background and then choose the action you want?
As far as I understand your description Preserving and Restoring State is what you are looking for.
Excerpt from Documentation:
The preservation and restoration process is mostly automatic, but you need to tell iOS which parts of your app to preserve. The steps for preserving your app’s view controllers are as follows:
Required
Assign restoration identifiers to the view controllers whose
configuration you want to preserve; see Tagging View Controllers for
Preservation.
Tell iOS how to create or locate new view controller objects at
launch time; see Restoring View Controllers at Launch Time.
Optional
For each view controller, store any specific configuration data needed to return that view controller to its original configuration; see Encoding and Decoding Your View Controller’s State.
Here is a link to Preserving Your App’s Visual Appearance Across Launches
Related
I want some advice on how to properly take on implementing state preservation and restoration for an app that has been build already, having lot of view controllers and complex hierarchy.
What are the things to be kept in mind when trying to preserve state for an app that is running for a while already?
EDIT:
I want to get clarified or possibly get a solution to a problem that I am facing in terms of restoring state goes. I successfully restore app' state on launch. I restore a view controller and other view controllers in hierarchy. Now when I push another view controller and sequence of other view controllers to nav. stack, at a particular view controller, for some reason the app crashes due to an exception. So when I open the app back, it still restores the first view controller's state that was preserved when pressing home button.
Specifically I want to know if there is any way to discard app state info. when app terminates due to uncaught exception? I know that the state will be discarded if user manually force kills app, or state restoration fails, or the app terminates at launch. Is there a way to catch a termination and configure app state accordingly? Suggestions would be great. Thanks.
From my understanding, state restoration should be done as we move along building the app
No, I don't think that's right at all. The whole beauty of the built-in state saving-and-restoration mechanism is that it can be patched right onto the working app, one view controller at a time. You don't even have to complete it for the whole app before testing; on the contrary, another beauty of the mechanism is that it works for just the subset of the view controller hierarchy for which it is in fact implemented, with no harm done to the rest of the app. So just start at the top of the view controller hierarchy and start implementing it.
I wonder how to launch the App from background with specific scene instead of always starts with launch screen or main.storyboard's initial ViewController.
For Example, if the user was viewing the profile scene and then make the app go to background from there, I would like to launch the same profile scene(without reloading or the profile pictures, bio, etc) the next time the user bring the app to the foreground.
Now the case is that the App always start with the launch screen and or the information that was loaded before went away.
How can I remember the specific scene when App enters background? By the way, I noticed this issue when I refractored the storyboard.
That's exactly what state restoration is for!
State restoration is a feature in iOS that lets a user return to their app in the exact state in which they left it – regardless of what’s happened behind the scenes.
You can enable it from your appDelegate by overriding application:shouldSaveApplicationState: and application:shouldRestoreApplicationState:
and having them returning true.
Then you will have to apply restorationIdentifier to your viewControllers (and yes, you can do it from the storyboard :) ). Doing so will allow your user to come back to the very screen / screen hierarchy they were when they last left...
You will however have to handle the logic the the data that need be displayed. In your viewController subclass, you can override encodeRestorableStateWithCoder: and decodeRestorableStateWithCoder: to store and then retrieve your data to display from the coder.
find the Apple doc here : https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/PreservingandRestoringState.html
And a Ray Wenderlich (love the man!) here : https://www.raywenderlich.com/117471/state-restoration-tutorial
I have an app (iOS, Swift) which is usually started in the morning by the user. The user will press a couple of buttons, enter some text, move to other views (using a navigation controller) and so on. When everything is filled out the right way, the user will put the iPhone into standby mode. As far as the app life cycle is concerned, it will enter the background state. When the user opens the app again, he will still be on the same page, with the same parameter, ... Everything is fine.
In case of a suspended app (due to a lack of resources or other stuff), the app will start again from the beginning and not from the view where the user has navigated to before. In such a case, what's the best way to navigate to the specific view the user was when bringing the phone into the standby mode and keep respectively build up the whole navigation stack as it was before the suspension?
You can use Apple state restoration and preservation technique for this purpose. Here you can find an example provided by Apple.
Hope this will help.
What I'm looking for is a mechanism to keep my app from resetting to the root view controller every time the application gets backgrounded or goes inactive. There are many apps out there that operate this way, namely Instagram, eBay, etc.
My instincts told me initially to poke into the AppDelegate's applicationWillEnterForeground method, where I would try to present the viewcontroller I'm after, however when I instantiate the viewController, I can present it, but without the navigation controller that normally be there.
This makes me think that I need to save the "state" of the application (maybe the NavigationController's stack?) and then restore the stack somehow when it gets relaunched.
I have watched the execution timings of each event and notice that closing the application and relaunching it will start the application fresh. I assume that my NSUserDefaults are still in place and thus could be checked for a logged in user. This could help determine which view in the navigation controller to push to (either login or dashboard).
Any direction is greatly appreciated.
The most revealing answer in this post was the use of some storage (NSUserDefaults) in order to store persistent data across uses.
For my specific case, this was storing a key holding user info. Then when the application loads, the would-be first view comes up, but if that key is missing, will modally pull a login view in front of it.
To do this I would use NSUserDefaults to store the current view of the app and then switch to that view when your app finishes launching. See the answers to this question: Swift: How to store user preferences?
I have "Tinder" like swipping view that is located in a CardViewController. The card View Controller is accessed by moving through two other view controllers. i.e. Load App -> FirstViewController -> SecondViewController - > CardViewController.
When I am in the Card ViewController and I go into background mode, the app launches on the FirstViewController and on going to the cards, they are loaded from the first card in a stack of about 10?
Is there anyway to load the app from the last Card I had swipped and in the CardViewController without having to navigate from the FirstView Controller again?
I would really appreciate the help as it's horribly affecting some of my users.
An example of a Tinder like card view is shown!
The problem, from the sound of it, is not what happens when the app goes into the background — that would leave it in exactly the same state when it reactivates. The problem is what happens when the app goes into the background and quits. Your app is then relaunched from scratch, which is why you find yourself in the first view controller. What's upsetting you is the difference between the app's behavior in these two situations.
Apple provides a solution to this situation: UIViewController, along with the App Delegate, has methods permitting you to save and restore state. When the app goes into the background, the current configuration (what view controller's view is showing) is saved. That way, even when the app quits, when it relaunches it can get back to that configuration before it appears to the user. Thus, coming back from background-and-quit looks just like coming back from mere backgrounding.
For full details, see Apple's documentation. This is a good place to start:
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/PreservingandRestoringState.html