Ok, so we all are aware (or should be) that 'UIApplicationExitsOnSuspend' can be set true or false in the info.plist file.
What I would like to know please, if possible, is if we can change the bool value of UIApplicationExitsOnSuspend in app.
Simply allowing the user to set whether the app is allowed to run in background, or wether it should just kill itself on the pressing of the home button.
Any help please.
It's not possible to change the value in the app.
However you could add a setting to your app and check wheter it's on/off in applicationDidEnterBackground:.
Something like:
if (theUserDoesNotWantMultitasking) {
exit(0); // doesn't generate a crash report.
}
It seems tolerated by Apple validation process even though I bet they're not recommending it.
Small precision:
By tolerated, I mean that I've done that once in an app, with a different use case (not based on a user setting). It has been approved, but I can't guarantee that it will always be the case.
It's not possible.
Calling exit from your app is going against Apple's advice. If you do so, you may find your app rejected at some future point.
Read the best practices: http://developer.apple.com/library/ios/#DOCUMENTATION/UserExperience/Conceptual/MobileHIG/UEBestPractices/UEBestPractices.html
Related
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."
In many applications, such as the Mail app, if the device is in airplane mode a notification will pop up that says "Turn Off Airplane Mode or Use Wi-Fi to Access Data."
I thought that this would automatically be invoked if my app tries to access the internet, but it is not. Is there a special method to do this, or if not how can I check if the device is in airplane mode and provide a link to Settings to disable it?
If you add the UIRequiresPersistentWifi key to your Info.plist and set it to YES, then if you're in Airplane mode, you'll get the standard "Turn Off Airplane Mode..." popup on launch.
I test in my app. I find it changed. "UIRequiresPersistentWifi" => "Application uses Wi-Fi".
I hope it will help somebody.
You could use the apple's reachablity framework when you app launches to check for network connectivity. Check this out
http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html
I have a wrapper class for reachbiltiy APIs to make it simpler to use. (ASIHTTPRequest has one as well).
https://github.com/daltoniam/GPHTTPRequest
see the GPReachablity class for checking for connectivity. As far as a dialog prompt, not sure there is a way to push to the settings app. Any questions let me know.
If you want the standard Turn Off Airplane Mode or Use Wi-Fi to Access Data [settings | ok]
Add a new property in your info.plist by clicking the + sign at the top.
The new property is called UIRequiresPersistentWiFi (this is similar to postings above, but needs to be exact otherwise it doesn't register)
Change type from String to Boolean
Change value from NO to YES
Clean and rebuild your app
Take a look at this. Apparently, Airport control was moved by Apple into a separate framework
It seems there is no standard way to notify the user to turn airplane mode back on. As you mentioned, this obviously isn't very elegant, so I assume apple deleted this feature.
I want to send my Application to background simply clicking on Button inside my Application.
Is there any way to call applicationdidenterbackground manually or any other way ?
iOS Human Interface Guidelines says "Don't Quit Programmatically", whereby quitting must be understood as including "suspending":
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.
If you really want to exit your app programmatically, then you can call exit(0);, but I doubt that you app will pass the Apple review.
Unfortunately There is no any officialy way to force app to background state(Pause state).
How can I suspend my application or send a suspend message to my application?
I want to simulate pressing the home button.
There is a private instance method for UIApplication:
The following code would work, (tested in an iPhone 3GS):
UIApplication *app = [UIApplication sharedApplication];
[app performSelector:#selector(suspend)];
In swift:
UIControl().sendAction(#selector(NSURLSessionTask.suspend), to: UIApplication.sharedApplication(), forEvent: nil)
Edit Swift3:
UIControl().sendAction(#selector(URLSessionTask.suspend), to: UIApplication.shared, for: nil)
Quitting your application or sending it to the background programmatically is a violation of the iOS Human Interface Guidelines, which usually doesn't bode well for getting through the review process:
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.
The philosophical reason for this is explained earlier in that document:
People, not applications, should
initiate and control actions. Although
an application can suggest a course of
action or warn about dangerous
consequences, it’s usually a mistake
for the app to take decision-making
away from the user. The best apps find
the correct balance between giving
people the capabilities they need
while helping them avoid dangerous
outcomes.
Users feel more in control of an app
when behaviors and controls are
familiar and predictable. And, when
actions are simple and
straightforward, users can easily
understand and remember them.
People expect to have ample
opportunity to cancel an operation
before it begins, and they expect to
get a chance to confirm their
intention to perform a potentially
destructive action. Finally, people
expect to be able to gracefully stop
an operation that’s underway.
There should be no reason that you need to force your application into the background during its operation. It should remain fully functional when displayed onscreen and it should be up to the user when they want to switch away from your application.
You can't do this.
If you want to exit your app, don't fear rejection and love false positive crash report emails from users you could call exit(0);
Use :
sleep(15)
it will suspend your app for specific time
When the application is suspended, a UIApplicationWillResignActiveNotification notification is posted.
I would guess you could try to post this notification manually. Didn't try this myself though.
I would like to close an iPad application as a result of clicking on a UIButton. However, I have not seen how to do this in the Apple documentation.
What call needs to be made to close an app?
Thanks.
You can call exit(0) to terminate the app. But Apple don't like this as this gives the user a feeling of sudden crash. If you still want to have an exit function (with a potential risk of rejection) then you should also send your app delegate the applicationWillTerminate message (if you have anything important there) before performing the exit.
It says:
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.
The only way for a user to exit an application is by pressing the Home button. You can't do it in your app, at least not in a way that Apple would accept.
You can try to use command:
exit(0);