I have an app that needs to fetch some remote configuration files before it starts or after it has been idle for some time in the background. I use a loader view controller to do the job while displaying a splash screen with a loading indicator.
What would be the best way to display the loader (assuming I also want to refresh the whole app after idle time in background):
Display as a modal view controller and dismiss when finished
Set the loader as root view controller and set back the original root when the loader finish (this method triggers a dealloc for the original root and creates it from scratch)
Go with option 1. I've used it many times and it works brilliantly. The best thing about using a modal view controller is that you can smoothly transition when you dismiss it, and you can just present it un-animated on applicationDidFinishLaunch so that it's there instantly for the user to see.
Display as a modal view controller and dismiss when finished.
This option will be more feasible when your app will starts from background state. You can show this with no animation show it will feel like splash and you can fetch remote configuration files.
Related
I have used the LaunchScreen.storyboard file in my swift file to create a launch screen, however I only see the launch screen when I load the app onto my phone. After that, even when I kill the app I don't see the launchscreen again. I want it so that it shows every time the app is booted, so after it's been removed from the background like most other apps that exist. I there a setting that i need to toggle, or am I doing something wrong?
What you want can be achieved from the initial ViewController instead of Launch Screen.
Reason: Launch Screen timing is not fixed and can have a very short appearance if the app has recently been in the memory.
I would recommend you to use the welcome graphic/animation on the initial View Controller and move to the intended View Controller after a set timer by using a segue.
Edit: Additionally, in case of a graphic, you can put that on the Launch screen as well, then on the initial View Controller. That will get you continuity.
Hope this helps.
Killing and relaunching iOS app, If I have View Controller A,B,C last visible View Controller was C. So now when I relaunch app i see View Controller C for 10 sec and then shows up Splash Screen. How can I avoid this.
Because of this first 10 sec User cant perform any event on app.
I think this is an operation system bug. But if you want to avoid this, you can try to add a splash screen image view before your app will go to background. You need to add your custom overlay view as subview to current window. Use this method to implement this feature: applicationDidEnterBackground. You can find more information about this feature here:
Display a view or splash screen before applicationDidEnterBackground (to avoid active view screenshot)
To force iOS to launch an app with its default viewcontroller or launch image, you need to call
UIApplication.shared.ignoreSnapshotOnNextApplicationLaunch()
where you implement state preservation.
Form the documentation : Documentation
Prevents the app from using the recent snapshot image during the next launch cycle.
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
Looking to see where the best place to call some endpoints for initial data is.
In some apps (mostly games) there is a loading screen before the menu. Is this the "Launch Screen" or is it a view set up during viewDidLaunchWithOptions, or is it simply an initial view?
If my searching was correct, there is no way to "perform logic" during the launch screen. So are apps that have a loading screen simply not using a launch screen and just setting up their own loading screen (which appears as a "launch screen")?
You can't execute any code in the launch image or launch storyboard scene, as it is displayed while your app is loading and before it has started executution.
A common approach is to create the first scene of your app to be identical to the launch storyboard scene, so that the transition between the launch image and the initial scene is seamless. You can then perform the loading in the initial scene, while providing appropriate feedback (spinner, progress bar etc)
Mostly it is recommended to use Launch screen Because if your first screen which you are using to shows animation takes long time to prepare itself then user will see white screen. And then perform animations on app's root view controller which always appear at app launch.
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