If the user received a call during application running, how to automatically open the application after call ended. And how to restore the last session, so that the user would not start from the beginning?
Thanks
You need to implement the following methods from the UIApplicationDelegate protocol:
applicationWillResignActive is called when the phone receives an incoming call
applicationWillTerminate is called when the user answers the call
applicationDidBecomeActive is called if the user choose not to answer the call
applicationWillTerminate will give a few seconds to save your apps current state. The easiest way to save state is through the NSUserDefaults class. When the app starts again you read your state from NSUserDefaults and restore the app to its previous state.
Related
I am working on an iphone game app. I dont want to use core data or nsuserdefaults to store user data. instead i want to keep all activities in memory and then send it to server when user goes back to previous screen, ends game or presses the home button of iphone. Now everything works fine but i am not able to sync user data when user presses home button. I have implemented the appilcationWillTerminate method in my delegate class but its not working out for me as the method is not get called when I press home button of iphone. Can anyone please tell me how to achieve this task?
best regards
What about this method:
Tells the delegate that the application is now in the background.
- (void)applicationDidEnterBackground:(UIApplication *)application
From Apple Docs:
In iOS 4.0 and later, this method is called instead of the applicationWillTerminate: method when the user quits an application that supports background execution. You should use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later. You should also disable updates to your application’s user interface and avoid using some types of shared system resources (such as the user’s contacts database). It is also imperative that you avoid using OpenGL ES in the background.
Your implementation of this method has approximately five seconds to perform any tasks and return. If you need additional time to perform any final tasks, you can request additional execution time from the system by calling beginBackgroundTaskWithExpirationHandler:. In practice, you should return from applicationDidEnterBackground: as quickly as possible. If the method does not return before time runs out your application is terminated and purged from memory.
You should use NSUserDefaults to store data about the application state. Then, when the application re-starts, you can load the data from NSUserDefaults to recreate the previous state. However with the new multitasking this is not as necessary as it used to be a couple of years ago.
whats the use of UIApplicationDidEnterBackgroundNotification in iPhone app or how we can take benifit from it
This notification means the user "quit" your app on an iPhone 4 - It happens when a phone call or text message comes in and user accepts the interruption (answers/replies), or when the user has pressed the Home button.
I found this link on SO that shows the interaction between all states, and the appropriate notifications:
http://www.drobnik.com/touch/2010/07/understanding-ios-4-backgrounding-and-delegate-messaging/
To make use of this notification you can implement applicationDidEnterBackground as #Antwan suggested (in your UIApplicationDelegate class - that's the main class).
Alternatively you could set up a notification handler wherever you want/need in your code:
[[NSNotificationCenter defaultCenter] addObserver: self
selector: #selector(handleEnteredBackground:)
name: UIApplicationDidEnterBackgroundNotification
object: nil];
Good luck!
Oded.
From apple documentation.
Tells the delegate that the application is now in the background.
- (void)applicationDidEnterBackground:(UIApplication *)application
Parameters
application
The singleton application instance.
Discussion
In iOS 4.0 and later, this method is called instead of the applicationWillTerminate: method when the user quits an application that supports background execution. You should use this method to release shared resources, save user data, invalidate timers, and store enough application state information to restore your application to its current state in case it is terminated later. You should also disable updates to your application’s user interface and avoid using some types of shared system resources (such as the user’s contacts database). It is also imperative that you avoid using OpenGL ES in the background.
Your implementation of this method has approximately five seconds to perform any tasks and return. If you need additional time to perform any final tasks, you can request additional execution time from the system by calling beginBackgroundTaskWithExpirationHandler:. In practice, you should return from applicationDidEnterBackground: as quickly as possible. If the method does not return before time runs out your application is terminated and purged from memory.
You should perform any tasks relating to adjusting your user interface before this method exits but other tasks (such as saving state) should be moved to a concurrent dispatch queue or secondary thread as needed. Because it's likely any background tasks you start in applicationDidEnterBackground: will not run until after that method exits, you should request additional background execution time before starting those tasks. In other words, first call beginBackgroundTaskWithExpirationHandler: and then run the task on a dispatch queue or secondary thread.
The application also posts a UIApplicationDidEnterBackgroundNotification notification around the same time it calls this method to give interested objects a chance to respond to the transition.
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.
I am developing one game application for iphone.Here whenever user get the call or SMS or he quit the appication ,my application should be in pause state .so,whenever he loads the application again,it should go to previous state where it stopped. Are there any built-in methods for doing this
Thanks all
Implement notification for UIApplicationWillTerminateNotification (and probably UIApplicationWillResignActiveNotification as well). That way your objects can save their state, and restore it when the application is relaunched. There are notifications for that, too, but you are more likely to want to read in the old state data when the objects receive their init calls.
You should consider all the usual storage mechanisms for state - NSUserDefaults, plists, and CoreData. The choice is up to you.
It is you who have to handle all this stuff. You have to save your object state into some file and reload the file when the app re-launches. The system provides you an opportunity to save the state by throwing notifications where in you have little time to archive your objects. Try to design your app such that the objects are not heavy weight and prioritize the object archiving tasks.
How can I check missed call in iPhone using Objective-C?
There is no access to the iPhone phone from third party software. Luckily.
The sandbox prevents access to the phone functions from third-party apps. Thus there is no way to detect missed calls.
Using Core Telephony framework, detect for call state changes.
Listen for incoming calls. Now your application will be notified when there is an incoming call.
After this, when the alert pops up, applicationWillResignActive is called.
If the user accepts the call, applicationDidEnterBackground is called, and then when user switches back to your application applicationDidBecomeActive will be called.
If the user rejects the call or the calling person ends the call before accept/reject, applicationDidBecomeActive will be called.
The second case indicates a missed call.
When you have an incoming call, the function
- (void)applicationWillResignActive:(UIApplication *)application;
is called and if the call gets missed, the application will be active again and the function
- (void)applicationDidBecomeActive:(UIApplication *)application;
is called.
This way, you can detect missed calls. There is no other method to do this that i am aware of.
The only drawback is that these methods are also called when you Lock/Unlock the device when your application is active so you will not be able to know whether it was a missed call or the user locked the device.