How to handle the phone call while running the application in iphone - iphone

I am doing with a paint application. while drawing any picture if I got any phone call, the application is getting quit and reopens immediately after end of the call. But my requirement is I should able to draw the picture while I am in incoming call.
Any one can Please help me out

When a phone call comes in, and the user picks it up, they will always leave the current app and the phone app will start. I don't think you can change this behaviour.
While the user is in the phone call, though, they can change to another app simply by pressing the home button and starting another app from the home screen, or by double-pressing the home button and switching to another app, including yours.
In that case there will be a thin view below the status bar indicating that they're in a call, so you have to make sure your app resizes properly to make space for that.

This is default from apple that any application go inactive if incoming call is in active.We cannot change this.

Use the below Appdelegate method:
(void)applicationWillResignActive:(UIApplication *)application
This delegate will call when the application is about to move from active to inactive state. This can occur for certain types of temporary interruptions (such as an incoming phone call
)
To Restart any tasks that were paused (or not yet started) while the application was inactive. For this use the below appDelegate
(void)applicationDidBecomeActive:(UIApplication *)application
For more visit app multitaking
Hope, this will help you..

Related

How to detect whether user didEnterBackground because of phone call or click on home button?

We have a multiplayer game and sometimes user quit the game so we would like to know how did user quit the game. Can we use didEnterBackground for that?
We would like to know whether user quit the game by clicking exit button, or by incoming call, or by home button to exit.
When you press home button your application is sent to background and applicationDidEnterBackground will get call first and if it is by call, sms then applicationWillResignActive will get call first.
This is not perfect answer of your question but this might help you in some.
in the appDelegate.m File u have this function:
- (void)applicationDidEnterBackground:(UIApplication *)application
write the code you want in it. (saving data or anything)
First of all, the user interface guidelines forbid quitting an app programmatically and based on what I have read, apps the provide an exit button will be rejected.
If by 'quit the game' you mean something along the lines of 'terminated gameplay', then that should not be a problem.
Also note that pressing the home button does not exit the app. It simply sends it to the background. There does not appear to be any facility to detect why the app left the foreground, which probably means that Apple wants your app to handle all such cases in the same way: by saving state and being prepared to restart where execution left off. Note that an application in the background can be terminated at any time, hence the need to save state.
The answer to your question therefore would seem to be: don't do that.

Is there a method if application was closed in multitasking?

Is there a method like: wasTerminated or something like that? I want to display the user an alertsheet, if he has completely closed the app from multitasking. At the moment I have implemented my code in the DidEnterBackround, but is there another way to fix this? That would be very useful for me.
Sorry I'm a newbie and I didn't find a solution on the net.
Thanks.
Background applications can be terminated at any time, and there's no way for an app to tell whether it was terminated by the user (through the multitasking switcher) or by the system.
Your only notifications are –applicationDidEnterBackground:, –applicationWillEnterForeground:, and –application:didFinishLaunchingWithOptions:. With these notifications you can tell if some background task completed or not, but you can't tell how your app was terminated.
Do you want to show the message to the user, next time the user starts your app, or when the app is killed. If the app is killed by double clicking on the home button and killing it, and if you want to find out then, it is not possible.
But if the app is killed and the user starts the app again, then you will know whether the app is started fresh or did it become active.
The method
-(void)applicationWillEnterForeground:(UIApplication *)application{
NSLog(#"Entering foreground");
}
will get called if it becomes active from background.
Other wise,
- (void)applicationDidBecomeActive:(UIApplication *)application {
}
will get called where you can put your alert view.
You can easily experiment with these situations and figure out a way to do what you want.

controlling when app will refresh when returning from background

This is a rather general question on what actually happens when an app returns from background. I have a user telling me that on opening my app that he has not used for over a day, he will still be shown the same view that he had before he closed the app (by "closed" I mean he just hit the home button to send it to background, NOT hold and then tap the cross button to kill the app completely).
I was on the impression that if an app is restored from the background after a long time, it will be reloaded completely (showing splash screen and everything), as in the cases when I opened facebook or gmail app after I haven't used it for some time.
So my question is, do I have to implement a check somewhere on the period of time passed since my app was sent to background and reset everything when it goes over a certain threshold, or is that supposed to be handled by iOS itself... and of course if a user sent my app to the background and return after 2 minutes I would not want to refresh
You might have to handle that in your appdelegate methods by setting a timestamp. Since multitasking is enabled in iPhones, it will start from the same screen again. An app can be in background for a long time until user decides to kill the app.
Some of the delegate methods are
- (void)applicationWillResignActive:(UIApplication *)iApplication;
- (void)applicationDidEnterBackground:(UIApplication *)iApplication;
- (void)applicationWillEnterForeground:(UIApplication *)iApplication;
- (void)applicationDidBecomeActive:(UIApplication *)iApplication;
If you want to disable multitasking you can do that by setting a UIApplicationExistsOnSuspend key in application plist. But that will make the app quit immediately when user presses home button.
The decision on whether your app should refresh after some period of time in the background is completely up to you and the needs of your app. An app could sit in the background for weeks without being killed by the OS. Or it could be killed seconds after going into the background. It all depends on resources being needed for other running apps.
If you want logic in your app that makes it restart after 24 hours, for example, then it is up to you to write code to handle this. Save a timestamp when the app goes into the background. When it returns to the foreground, compare the current time to the saved timestamp. If enough time has passed, you need to update your UI to reflect whatever desired state you want to show the user.

Which function is called when iPhone app is terminated?

I'm working on a project in Xcode version 4.2.1 and in iOS 5.0. I'm wondering which function will be called when you completely terminate an application, which means even the time when an users force the app running on background to be terminated from home screen. I was assuming that
(void)applicationWillTerminate:(UIApplication *)application
would be called, but it turned out it was not called even after terminating the app on background.
What I basically want to do is to call a method that I created just before the app is completely terminated, so need to know which function is called at the end of the app.
Thank you.
"applicationWillTerminate" method will be called only when application is not in suspended state while being terminated.
To understand this, considering currently your application is in foreground active state, go through following two cases:
Case 1: When you single tap Home button, app directly goes to suspended state by calling methods - (1) applicationWillResignActive and then (2) applicationDidEnterBackground.
Now when you try to quit/terminate app, by double tapping home button and then swiping up the current app screen from recent app screens, app is in suspended state. So, "applicationWillTerminate" method will not be called.
Case 2: When you double tap Home button, app goes to inactive state by calling method - (1) applicationWillResignActive.
Now when you try to quit/terminate app, by swiping up the current app screen from recent app screens, app is in inactive state (not in suspended state) while being terminated. So, "applicationWillTerminate" method will be called.
Look what Apple say:
For more info on this look - Apple's Official Documentation on applicationWillTerminate(_:)
Here's a good overview of the application lifecycle notifications & delegate messages on iOS 4.0 and newer. In short...
Your app will generally never see willTerminate, because the system generally only terminates your app once it's already suspended (in the background). Once your app is suspended, it gets no further chance to act(*), so there's no callback for that.
The didEnterBackground delegate message or notification should be considered your last chance to clean things up or save state before possible termination.
(*) Okay, your app can do stuff if it's in one of the supported background execution modes, like audio, VoIP, or navigation, but in that case it either hasn't been suspended yet or it's been un-suspended with an entry point specific to that background mode.
If the app is already suspended, it will not receive further notifications. Watch for the didEnterBackground notification.
- (void)applicationWillTerminate:(UIApplication *)application
It's in the UIApplicationDelegate protocol.
The documentation here spells out the behavior for this case.
In short, you'll only receive the applicationWillTerminate: message if the app is running (either in the foreground or background) when it's terminated. So, unless your app is running in the foreground or in one of the long-running background modes (e.g. VoIP, Audio, or a long-running task indicated by beginBackgroundTaskWithExpirationHandler) it will transition from the background state to the suspended state fairly quickly. In this case, you'll never receive the applicationWillTerminate: message.

iOS home button warning, is it possible?

I really don't think this can be done, but still my boss wants me to provide a link where it says so. What he wants is to add an 'are you sure you want to exit?' warning when the user presses the home button, and if the user says 'no' the app won't go inactive.
It can't be done, can it?
No, you cannot do this - the application has no say in this. Ask your boss whether he has ever seen a single example of an iOS application that would do this. There isn't ... not one I would bet.
The application can continue to execute some functionality in the background - streaming music, getting location information for example, but no application can block the home button. If you could do this, you could block an application from ever closing.
A) You couldn't technically do this and
B) Apple wouldn't allow it to be released on the App Store if that was the distribution route you were taking
If you look at the methods stubs created by XCode when you create an application delegate
-(void)applicationWillResignActive:(UIApplication *)application
-(void)applicationWillTerminate:(UIApplication *)application
That are filled will comments about how you can use this method to pause tasks, disable timers, throttle down frame rates, save data - there is nothing about being able to delay, query the user with an "Are you sure" message.
This whole idea is rather counter to the user-experience of the iPhone/Pad/Pod-Touch.
From the App Store guidelines (slightly abbreviated):
Apps that alter the behavior of switches on the device will be
rejected
This is a proposed change the behavior of the home button - so would be rejected.
This is possible on a jail broken device, using un-aproved API's. The concept is in multiple violations of apple's usage policy however so you would never, ever, ever get an app attempting to implement this in any way on the official app store. Here's just a few reasons:
You can't alter the functionality of any buttons (including the volume buttons, some camera apps used to use them to take pictures, but they got booted from the store as a result).
You can't interfere with standard user interactions with the device. The home button takes people home, you can't prevent that, or ask for confirmation as that would be interfering with the interaction.
There is no public API to detect actual usage of the home button. As such you would need a private API, and you can not use private API's without explicit permission from Apple, which they would never give due to #1 and #2 above.
I'm sure there's plenty of more reasons, but regardless it would be in direct violation of app store policies as well as iOS human interface guidelines.
You can detect when the app is about to lose focus, has lost focus, or could loose focus (such as a phone call is coming in) but you can not alter the flow (i.e. not allow the app to lose focus).
You can continue to execute code in the background within the backgrounding guidelines and limitations. The backgrounded code could submit a notification to the user that would allow them to switch back into the app... that's about as close as you could get, and expect apple to reject you if it happens every time the app closes...
Already answered by numerous others, but no, you can't do this. When the user presses the home button, your application delegate's applicationWillResignActive is called which disables touch events to the application. Then applicationDidEnterBackground is called, which, per the Apple docs:
Your delegate’s applicationDidEnterBackground: method has
approximately 5 seconds to finish any tasks and return. In practice,
this method should return as quickly as possible. If the method does
not return before time runs out, your application is killed and purged
from memory
You need proof to show your boss that obviously isn't an iOS developer.
Apple Human Interface Guide
That should be all the proof you need. But to be clear, Apple will not allow an app to override the home button in any way. You can surely put action sheets or pop ups to warn before logging out, but once the home button is pressed, you are on notice to give up your memory, you are being shut down.
You might want to look into the Store Demo Mode of IOS. This way you can disbale the Home button and lock the device in the first app you start after booting.
I know I'm too late to answer this question.
But I recently came with the issue which Samssonart had.
The answer given by #iandotkelly is deprecated with iOS5. Now none of delegate method will be used to distinguish between locking the device or sending app to background using Home button.
you can now use applicationState variable to define what action is triggered.
applicationState is an inbuilt id provided by appDelegate.
**
if it returns 2 then, it will identify the Home button is pressed
if it returns 1 then, it will identify the lock hardware button is pressed
**
So, in your case you can check out this condition in **applicationDidEnterBackground** method
- (void)applicationDidEnterBackground:(UIApplication *)application
{
NSLog(#"decision >> %d",[[UIApplication sharedApplication] applicationState]);
}
Enjoy Programming!
The best reference I can find is this one. It's not quite explicit, but Apple's Human Interface Guidelines have a couple of headings 'Always Be Prepared to Stop', followed by 'Don't Quite Programmatically', which spell out what the home button does and that you shouldn't be implementing your own quitting strategies.
I know this is an old topic, but I just want to update this answer. In iOS 7 this is not working.
So I use screenbrightness when the app will go to the background to identify difference between the Home and Lock button.
-(void)applicationDidEnterBackground:(UIApplication *)application {
if ([[UIApplication sharedApplication] applicationState] == UIApplicationStateInactive) {
NSLog(#"Sleep button pressed");
} else if ([[UIApplication sharedApplication] applicationState] == UIApplicationStateBackground) {
if ([[UIScreen mainScreen] brightness] > 0.0)
NSLog(#"Home button pressed");
else
NSLog(#"Sleep button pressed");
}
}
I hope this is gonna be of any help for in future for anyone