I my testing, when I exit (by pressing the home button) my app, it still is "running" in the background, thanks to the multitasking feature. However, I would like it to quit when the home button is pressed. Is this only happening to me?
Anyway, I have tracked it down to the applicationWillResignActive and the applicationDidBecomeActive methods in the app delegate. These get called for multitasking, but when I want to terminate, the app "resigns active." Any guidance on this issue is greatly appreciated!
Your application can opt out of multitasking (see the appropriate section in the iPhone Application Programming Guide) by adding the UIApplicationExitsOnSuspend key to your Info.plist and setting its value to YES.
In practice, Apple strongly recommends you not do this unless you have a very good reason for this behavior.
I think it's more efficient to suspend an app, when pressing the "Home" button. There's overhead in constantly launching and terminating apps. It's worse for the iOS operating system, and it's worse for user experience - because they need to wait for the app to launch again. Not sure what benefits you gain from terminating an app. If it's for simulation testing, my advice is to avoid that functionality, because your testing environment should be as realistic as possible. If your purpose is to clear cache or to make updates - that can all be done programmatically from subroutines.
Exiting subroutines
applicationWillResignActive
applicationDidEnterBackground
applicationWillTerminate
Entering subroutines
applicationDidBecomeActive
applicationWillEnterForeground
applicatonDidFinishLaunching
If you still insist on terminating an app when the user presses the "Home" button, despite the costs mentioned above - then set the UIApplicationExitsOnSuspend to true in your Info.plist as suggested by Brad Larson.
I wouldn't recommend trying to control the user's HOME button... deciding for them "exit" or "suspend".
I WOULD like to have HOME do an instant EXIT in the iPhone simulator... but haven't found any way to do that.
Related
If I send my app to background by clicking the home button and wait a certain time (perhaps 1 or 2 hours).
What will happen if i tap on the app icon now?
Will the app relaunch or simply be brought from background to foreground?
Quick "prologue":
Welcome to the wonderful world of stack overflow (SO), I myself am rather new here, but found it much friendlier to use welcome you anyway!
Just in case you haven't: Before you ask a question please look around a bit on SO in case someone else has asked the same thing, but if you can't get your question answered from that, then you should of course ask your own question.
Answer:
This question has no definite answer, because it depends. When you tap the home button your app enters, as you've said, the background and is still running to a certain degree. However after done so, the apps life cycle is up to iOS (the devices operating system) to determine. iOS controls and checks memory and CPU usage (etc..) of the device, and if you start another activity while your app is in the background that makes the available memory and CPU etc of the device not sufficient, iOS will terminate any apps in the background to not waste those resources (or battery etc). If so your app will relaunch next time you tap on it.
Although if you don't do anything performance heavy it is more likely that iOS keeps your device running in the background.
I'm not sure about the exact conditions and such the iOS works on, but i would say its very likely your app will have gotten terminated and is relaunched after 1 or 2 hours "in the background". Additional conditions apply if the device is locked during that period.
For proper documentation of this i would recommend reading Apples documentation for handling App State Transitions and/or the api for UIApplicationDelegate on apples developer website. Where you can see what the different methods in the AppDelegate does and how they interact.
Edit (answer to comment):
A way to relaunch the app everytime it goes into background?
Hm, yes, but also no. I'm not 100% sure about this (never encountered that "wish" before), but you can do this in your AppDelegate: (It will basically crash your app, but beware that apple does not encourage you to crash your own app anywhere). Doing this might stop the app from passing through apple store review process (i.e. your app might not be accepted to the App Store).
func applicationDidEnterBackground(_ application: UIApplication) {
exit(0)
}
Check out the answer to these post for a bit more information: call exit(0) in iphone app , objc - Proper way to exit iPhone application?.
Personally I would recommend you to work around it and don't do this. Also remember that when your app will enter the background applicationWillResignActive will be called and when the user opens it again, applicationDidBecomeActive gets called so you can do a reload or something from there if you want to refresh any data.
Whenever we press the home button in our device, the application releases the currently being used memory and moves to background stage. However, when we press this application app icon again it brings the app on top of the iPhone screen and occupies memory again. This is definitely not the relaunch because relaunch depends upon the UIApplicationDelegate method
didFinishLaunchingWithOptions. When we are switching app from background to foreground then applicationWillEnterForeground method fires.
For better understanding, the following link might be useful
iOS Application Life Cycle
I have an app when a specific action fires I close the app and ask the user to reopen it again.
The problem is when the app executes exit(0) the app stays in the apps stack (when I click the home button twice). I want it to be killed completely so that viewDidLoad() will be executed again when the app opens.
You cannot terminate an app on it's own.
From Apple's Human User Guidelines...
Don’t Quit Programmatically
Never quit an iOS application programmatically because people tend to
interpret this as a crash. However, if external circumstances prevent
your application from functioning as intended, you need to tell your
users about the situation and explain what they can do about it.
Depending on how severe the application malfunction is, you have two
choices.
Display an attractive screen that describes the problem and suggests a
correction. A screen provides feedback that reassures users that
there’s nothing wrong with your application. It puts users in control,
letting them decide whether they want to take corrective action and
continue using your application or press the Home button and open a
different application
If only some of your application's features are not working, display
either a screen or an alert when people activate the feature. Display
the alert only when people try to access the feature that isn’t
functioning.
Have a look at this answer: https://stackoverflow.com/a/8491688/742298
OK, this is pretty basic but I've read the documentation over and over and want to be sure I've got this right. In plain language, my watchkit app will be shut down by some user interaction exiting the app that's external to my code, right? I don't need to clear or reset the screen with any kind of close procedure that sets it up for another run? I don't need to build an "Exit" or "Close app" routine, right? It's confusing because the documentation implies the app will deactivate once it's no longer on screen (presumably by a user action like swiping to another app) and that this will call the didDeactivate function. But the documentation also claims:
In iOS Simulator, WatchKit calls the didDeactivate method for the current
interface controller when you lock the simulator by selecting Hardware > Lock.
When you subsequently unlock the simulator, WatchKit calls that interface
controller’s willActivate method again. You can use this capability to debug
your activation and deactivation code.
But the simulator doesn't appear to deallocate memory or reset variables or reset my app in any way. It remains persistent on screen in the state at the time of the lock, and it comes back in that state when I unlock. What worries me is that if I've got this wrong, I have an app built for one run. But I don't see routines for shutdown, screen clearance, or any of the elements you'd expect in a conventional shutdown routine.
I agree that the documentation can be confusing. The easiest way to think about it is that willActivate is called whenever your interface controller is displayed/activated. Likewise, didDeactivate is called whenever it is hidden/deactivated. So, if you're flipping through pages of controllers, each will receive a willActivate when it shows up and a didDeactivate when it disappears. Similarly, if a controller is deactivated because the app is no longer visible (e.g. it was suspended), didDeactivate will be called. If the user then raises their wrist to resume the app, willActivate is called, because the interface controller is being displayed.
There is no promise about whether your WatchKit app will be suspended or terminated (it's up to the OS), so you have to consider both possibilities. Based on experience, I know that dropping your arm will call didDeactivate before suspending your app. If you then raise your wrist, the app will resume and call willActivate. In my testing, the app was simply suspended (not terminated) in this situation.
You're correct that there is no built-in method that is called when the app is terminated. However, iOS 8.2 added four notifications that can be used to monitor the app/extension's state:
NSExtensionHostDidBecomeActiveNotification
NSExtensionHostDidEnterBackgroundNotification
NSExtensionHostWillEnterForegroundNotification
NSExtensionHostWillResignActiveNotification
I am facing the above issue and unsure why it is happening or how to fix it. When the app goes to the background and is later reopened, it always starts from the initial view.
I would like it to show the view that was shown when the app was dismissed - which is usually the default for iOS apps.
Can someone please explain why this might be happening and how I can resolve it.
Your app is probably killed while in the background to free it's resources for other tasks.
If applicable you can opt to use a background mode for your app so it keeps running in the background. This is possible if you require location updates, play audio or interact with bluetooth le devices.
By your description it's more likely you want to implement State preservation and Restoration (Programmig Guide)
Even if your app supports background execution, it cannot run forever. At some point, the system might need to terminate your app to free up memory for the current foreground app. However, the user should never have to care if an app is already running or was terminated. [...]
The state preservation system in UIKit provides a simple but flexible infrastructure for preserving and restoring the state of your app’s view controllers and views.
If you are on an iPhone older that the 3GS, this is normal. Apps are closed instead of backgrounded on these older models.
The other possible reason is that you've set
UIApplicationExitsOnSuspend=YES
in your Info.plist. In that case, your app will also always terminate when going to the background.
I have an app which crashes everytime when I resume it.
I want that when user clicks Home button, the app should close rather than go in background mode.
Is that possible?
If yes, please let me know.
If not, what could be the workaround so that my app does not crash when I resume it?
Thanks!
In the plist, set YES to Application does not run in background key.
When ur application is in background, due to memory insufficient, the views (and the objects released in viewDidUnload) might be released. Again when reopen the application, make sure all the required objects are re-initialized.
To opt out of background execution, see this thread... But ideally what you should do is fix the crash and let app user enjoy iOS background feature..
what could be the workaround so that my app does not crash when I
resume it?
Never think of work arounds when you can handle it straight..