How can I check if user has exited the app, so I can make sure the app will shutdown?
I am currently using Swift - Xcode 6.3.1
In the AppDelegate class (AppDelegate.m) there is a function called applicationWillTerminate:(NSNotification*)notif. This function will be called when the application has been quit. This is where you put any code that you have to call before quitting the app (e.g. closing files, deleting timers, etc). This is automatically called when the app closes, you don't have to check yourself.
In iOS you don't (in general) terminate an app. You should design your app such that if the user moves away from it (e.g. presses the Home button) that it is ready for when they decide to come back. You also need to design it such that if iOS terminates it (e.g. due to memory limitations) that no user data is lost and that all is right next time the app launches (the general guidance here is that the user cannot tell that the app terminated - but a lot of apps don't succeed in that). But otherwise you do not need to do anything when the user 'goes away' from your app.
See this Apple document for the official line on not terminating. See this Apple document for more details on the App lifecycle in iOS.
The sole exception is that you may want to terminate if a fatal error occurs - in Swift you can use fatalError to do this, but it will look like a crash to your user.
Related
I'm new to swift and programming so I'm not sure if or how this is possible, but could anyone tell me if I can designate code to be executed when the user terminates the app from the multitasking menu? I just have a line of code that I would like to execute at that time, but I'm not sure where to put it in my project.
Thanks!
If the user terminates the app from the multitasking menu, your app is killed dead. It is not terminated "in good order". You do not get an event at that time. It's just like the scene in 2001: A Space Odyssey where the scientists are already in suspended animation and HAL pulls the plug on them.
The art of Cocoa / iOS 8 programming is the art of the possible. Adjust your desires to fit the reality of the events you do get. You get an event when the user leaves your app, so if there is something you need to be sure to do, do it then, as you may never get another chance.
As matt said, when the app is terminated from the multitasking menu, none of your code is run, it's just killed.
Try putting your code into the application delegate's applicationWillResignActive(_:) method. This will run any time your app becomes inactive, though. In other words, more often (all the time) than being terminated in the multitasking menu. It'll run when there's an incoming phone call or text, I believe it will run if there is a notification with an alert, it will run when the user presses the home button.
My application uses the core location also after the application terminates with the method startMonitoringSignificantLocationChanges in CLLocationManager class.
My application launches with a location key in iOS 5 and 6 in the method:
- (BOOL) application:application didFinishLaunchingWithOptions:launchOptions;
in AppDelegate class and everything works well.
But in iOS-7 betas the application doesn't launch with a location key after a significant location change.
Has anybody encountered this problem?
I tried it on a simulator and in the device.
Thanks for the help.
I have the same problem in my app, when the app was terminated by user from app switcher.
But it does launch with location key if it was terminated by OS for low memory or other reason.
It is the expected result from iOS7 unfortunately. An official apple response I got from one of their evangelists:
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.
Attach link to Apple DEV forums:
https://devforums.apple.com/message/882691#882691
Does anyone know if exit(0) is deprecated in iOS application? I know it is not a good decision to manually terminate the app, but does Apple ban the application if we use it in the code?
I got an app which was rejected because of a way of exit (via UIAlertView), doing an exit(5) when user click on the correct button.
I received that:
We found that your app includes a UI control for quitting the app.
This is not in compliance with the iOS Human Interface Guidelines, as
required by the App Store Review Guidelines.
Please refer to the attached screenshot/s for reference.
The iOS Human Interface Guidelines specify,
"Always Be Prepared to Stop iOS applications stop when people press
the Home button to open a different application or use a device
feature, such as the phone. In particular, people don’t tap an
application close button or select Quit from a menu. To provide a good
stopping experience, an iOS application should:
Save user data as soon as possible and as often as reasonable because an exit or terminate notification can arrive at any time.
Save the current state when stopping, at the finest level of detail possible so that people don’t lose their context when they start the
application again. For example, if your app displays scrolling data,
save the current scroll position."
It would be appropriate to remove any mechanisms for quitting your
app.
A "hidden" exit could be understood as a crash for the user, no?
No, Apple will not reject your app for using exit(0).
You are correct, it is not a great design choice, but it can be useful sometimes.
As Larme mentioned, if used incorrectly, it can be perceived as a crash and a crash will result in your app being rejected.
However, it can be very useful in applicationDidEnterBackground when (on a conditional basis ) you might want to force the app to start a fresh.
No, you must not call exit as your app SHOULD be rejected. This has been repeatedly discouraged by Apple and is known to cause serious bugs with iOS multitask switching. You should simply leave the user to use the home button themselves.
http://developer.apple.com/library/ios/#qa/qa1561/_index.html
"Additionally, data may not be saved, because -applicationWillTerminate: and similar UIApplicationDelegate methods will not be invoked if you call exit. If DURING DEVELOPMENT or TESTING it is necessary to terminate your application, the abort function, or assert macro is recommended."
2012-04-09
Updated to more strongly discourage the exit function, and include best practices for debugging.
2008-08-27
New document that discusses best practices for terminating an iOS application in code.
Straight from the iOS Human Interface Guidelines
http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices.html#//apple_ref/doc/uid/TP40006556-CH20-SW27
"Don’t Quit Programmatically
Never quit an iOS app programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your app 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 app 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 app. It puts users in control, letting them decide whether they want to take corrective action and continue using your app or press the Home button and open a different app
If only some of your app's features are unavailable, display either a screen or an alert when people use the feature. Display the alert only when people try to access the feature that isn’t functioning.
If Necessary, Display a License Agreement or Disclaimer
If you provide an end-user license agreement (or EULA) with your iOS app, the App Store displays it so that people can read it before they get your app.
If possible, avoid requiring users to indicate their agreement to your EULA when they first start your app. Without an agreement displayed, users can enjoy your app without delay. However, even though this is the preferred user experience, it might not be feasible in all cases. If you must display a license agreement within your app, do so in a way that harmonizes with your user interface and causes the least inconvenience to users.
If possible, provide a disclaimer within your app description or EULA. Users can then view the disclaimer in the App Store, and you can balance business requirements with user experience needs."
So here is the issue I am facing. Certain portions of the application I am building open some c network sockets that allow connections to various servers/services. However, if the application goes to sleep, these socket connections are lost, and error out when trying to reload them. So what I want to do is basically notify the user when the app launches again, that the application needs to be restarted. The main question is, can I present them with a button that will kill the app by using exit(0) without my app getting rejected?
Apple says that the user should be in control of when the app is killed, and in this case I see that they are, but I am not sure of Apple's opinion on this. Has anyone else used this? Have you been rejected for this? Thanks in advance for any advice!
EDIT:
Thank you everyone for your advice. I am trying to take everything into consideration, but because the app needs to be submitted ASAP, I just need to know, if we can not get another solution, if the above proposed solution, will get rejected or not.
Your application delegate receives notifications when significant events affect the life of the application. Rather than ask your user to recreate a session, you should attempt to discontinue network operations and then resume them at the appropriate times in the application's lifecycle automatically.
You can gracefully kill network sockets (amongst other things) in any number of places as the application prepares to exit or enter the background via callbacks in your application delegate:
applicationWillResignActive:
applicationWillEnterBackground:
applicationWillTerminate:
Potentially reconstruct sockets in:
applicationDidBecomeActive
applicationWillEnterForeground
Have you tried not allowing the app to run in the background? Then it will be killed whenever the user exits to the home screen. This might be a bit aggressive, but would solve the problem. From Apple's opting out of background execution:
"If you do not want your application to remain in the background when
it is quit, you can explicitly opt out of the background execution
model by adding the UIApplicationExitsOnSuspend key to your
application’s Info.plist file and setting its value to YES.
When an application opts out, it cycles between the not running,
inactive, and active states and never enters the background or
suspended states.
When the user taps the Home button to quit the application, the
applicationWillTerminate: method of the application delegate is called
and the application has approximately five seconds to clean up and
exit before it is terminated and moved back to the not running state."
See also: How to prevent my app from running in the background on the iPhone
The documentation is pretty explicit about this, "There is no API provided for gracefully terminating an iOS application." See Technical Q&A QA1561
How do I programmatically quit my iOS application?.
To be blunt, terminating an app to cleanup a socket is just like dealing with memory management by forcing an app to exit instead of calling release.
What about bringing up a modal view controller telling the user to quit the application? You could make this view controller without any dismiss button, so the user is obligated to kill the app.
How can I quit iPhone4 app? When I use exit(0) the app goes in the background. I want to quit the app instead of sending it to the background.
iPhone apps shouldn't have a quit button. The user quits by pressing the main button.
From Apple's docs: (http://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdf)
People quit an iPhone application by opening a different application. In particular, note that people don’t tap an application close button or choose Quit from a menu. In iOS 4.0 and later, and on certain devices, the quitting application moves to a suspended state in the background. All iPhone applications should:
Be prepared to quit at any time. Therefore, save user data as soon as possible and as often as reasonable.
Save the current state when stopping, at the finest level of detail possible. For example, if your application
displays scrolling data, save the current scroll position.
iPhone applications should never quit programmatically because doing so looks like a crash to the user. There may be times, however, when external circumstances prevent your application from functioning as intended. The best way to handle this is to display an attractive screen that describes the problem and suggests how users can correct it. This helps users in two ways:
It 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
Set UIApplicationExitsOnSuspend in your application's plist. This will cause the app not to go into the background under iOS4 when the user switches to another app.
Then have your app send an openURL: message to Safari when your app wants to exit. When Safari launches, your app will be terminated (by honoring the UIApplicationExitsOnSuspend plist key).
If you point the Safari URL at a web page explaining why your app just stopped running, the user might be less likely to give it a 1-star rating.
Note that this procedure may or may not follow Apple's recommendations, but it does stay within legal public API use (e.g. even some of Apple's example apps launch Safari).
after that I put everything I had said I put this and it worked
- (Void) applicationDidEnterBackground: (UIApplication *) application
{
exit (0);
}
comes completely out of the application
in app delegate there is method call applicationDidEnterBackground
call the exit(0)