Is this now a mandatory requirement before uploading to the app-store? As I understand it, making my app compatible with multitasking is something extra that I need to implement. (?)
No.
It's not something extra. It's an opt-out process. Read this Apple doc.
My personal opinions is that if you don't actively support multi-tasking, you should opt-out from it.
Your app does not need to take advantage of the multitasking features, but it DOES need to gracefully handle being put in the background and never receiving a notice that the application will quit. More specifically:
Under previous versions of the OS when the user quit the app (by pressing the home button) the App Delegate's
applicationWillTerminate
was called. Under iOS 4 pressing the device's home button instead puts the app in the background, calling the App Delegate's
applicationDidEnterBackground
When the app is brought to the foreground again the OS call's the App Delegate's
applicationWillEnterForeground
This most commonly caused trouble for older apps when state changes -- user preferences, data files, high scores, etc. -- were being written out and saved when applicationWillTerminate was called. Now that it's no longer being called, some apps fail to save user information.
Most anything that you were doing when applicationWillTerminate was called should now also be placed in applicationDidEnterBackground, depending on what your app does.
Additionally, it's possible that some things you were doing in application didFinishLaunchingWithOptions will also need to be done in applicationWillEnterForeground, depending on what your app does.
It is not mandatory to support multitasking.
To disable multitasking, you can use the UIApplicationExitsOnSuspend key in your info.plist file, which may appear as "Application does not run in background."
See http://developer.apple.com/library/mac/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html for more information.
Related
My app has to run for a long time (also) in the background, due to Location Services.
When a certain condition is met the app has to move to the foreground.
I was able to run my app in the background and bring it to the front manually.
Reading up on this issue I got confused on how to move my app to the foreground by code.
It has to be in an if statement but what to do from here?
No do not think this is possible. You will be able to spawn a UILocalNotification to show application state to the user, but it is my understanding that iOS prevents you from making your app take focus.
you can't do that without user interaction. You can present a UILocalNotification
-- you can't even be sure iOS leaves it running though!
on a jailbroken phone I guess it is possible
This is clearly not possible, as it would be a mess if any app could just take over control at any point in time. As mentioned, you have to post a notification, and then it is up to the user if he or she wants to launch the app. If you notification states a good reason why they should launch your app, they might very well do it :-) And remember, don't mix up the user's needs with your/your app's needs.
While the device is powered on, is it possible for iOS to automatically terminate my app (calling applicationWillTerminate:) while it's in the background?
I'm also curious what happens in two other cases, three in total:
Device is powered on
Device is powered off
Device loses battery
I'm asking because I want to know how often applicationWillTerminate: is likely to get called. I want to know this because that's where I'm registering for remote notifications. And if there's a failure sending the device token to the server, I want to know how likely it is that that method will get called again (i.e., retry sending the device token to the server).
If your application supports multitasking (the default for anything linked against iOS 4.0+), this method will almost never be called. The documentation says it may be called in cases where the application is running in the background and the system wants to terminate. However, in my experience, I've only ever seen this actually called when running a music app that's actively playing music in the background and the system is jettisoning everything. In cases where I have background tasks running (not music, but short-term background tasks), I've seen the app terminated without this method being called.
I wouldn't ever rely on this being called and try and do all the clean-up you need to do in your delegate methods for transitioning into the background and your background task completion blocks (which do get executed for at least a few seconds before the app gets jettisoned).
Not only can iOS terminate your app automatically, but the user can kill it manually. In fact, the only time the user can kill your app is when it's in the background. Furthermore, when your app is "in the background" it's more likely to be suspended than actually running, so don't count on doing a lot of processing when you're not the foreground app.
As for how likely it is that you'll get -applicationWillTerminate:, that'll depend on the user and how they're using their device. You should handle it appropriately when you get it, and go about your business otherwise.
When memory is running low, iOS can shut down your app, calling applicationWillTerminate.
The docs say this about the method:
... However, this method may be called in situations where the application is running in the background (not suspended) and the system needs to terminate it for some reason.
Check out iOS Developer Library : iOS App Programming Guide : App Termination.
I have an app that will run in the background but there is one case where I do not want that to happen, can I achieve this programmatically?
I know I can opt out by changing this plist value but what about at run time?
Add the variable UIApplicationExitsOnSuspend (Application does not run in background) to your applications plist and assign the value YES.
You can close the app by calling exit(0) in applicationDidEnterBackground.
You can't use exit(0) b/c apple does not allow you to close the app without user knowing it.
From Technical Q&A QA1561 How do I programmatically quit my iPhone application?.
There is no API provided for gracefully terminating an iPhone
application. Under the iPhone OS, the
user presses the Home button to close
applications. Should your application
have conditions in which it cannot
provide its intended function, the
recommended approach is to display an
alert for the user that indicates the
nature of the problem and possible
actions the user could take - turning
on WiFi, enabling Location Services,
etc. Allow the user to terminate the
application at their own discretion.
Calling exit() is discouraged, and not informing the user that the app is going to terminate is also discouraged. So you need to get the OS to kill your app (as it normally would do over a long enough period of operation) while simultaneously informing the user. One way of doing this, while using only legal APIs, is to dirty absolutely as many memory pages as possible (malloc and bzero), then call Safari with a URL to a hoggish website explaining why the app is going to quit. Safari will require enough memory to display the website that your app will be terminated by the OS, just as the user is being properly informed.
Sleeping until the OS kill timer kills your app will also kill your app, but this non-responsive delay will lock up the UI, which isn't a good user experience.
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)
My application uses NSUserDefaults to store some values so that it can restore them on application update or if backgrounding is quit. Backgrounding automatically saves my integer values, but if the user quits the application from the launcher, the numbers are lost too, and the ViewDidUnload method I guess doesn't evoke when entering backgrounding. Is there a way that I can save the NSUserDefaults any time the application unloads. Also, the ViewDidLoad method had the same problem, it doesn't evoke from backgrounding. What's a way around this?
P.S. So far the only data my application needs to save is an int for an on-screen count.
UPDATE: UIApplicationDidEnterBackgroundingNotification works great with your suggestions!
You can't save data right before it eventually gets killed, but you can save state 'just in case' in your applicationDidEnterBackground: app delegate.
There's also applicationDidBecomeActive:, but there's no reason to load your save data from there, since when it's invoked from an app that was in the background, the data will have been preserved any way.
You can't tell if your app was launched from the background or not, at least how it's currently set up, since your app delegate will get the same sequence of events if it's launched from springboard.
As Joost says, you should save anything you need to restore state inside the applicationDidEnterBackground callback; essentially, you should assume this is the last message your app will get before it gets killed mercilessly by an evil process reaper.
You should check out the WWDC 2010 Session Videos, specifically, Session 105 - Adopting Multitasking on iPhone OS, Part 1 for a thorough explanation.