As in my application if some action regarding "httpcall" are posted in the mainthread and my app is waiting for a response from server and same time home button is pressed than although app is entering background but IOS delegates (such as "didEnterBackground") are not getting called till the response are received.
Also sometime even if I'm relaunching the app its not responding till it gets crashed by itself.
Note:I'm using CyberLink code for my HTTP posts.
As Apple says :
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)
I think you try to do something in background, for which didEnterBackground is not enough. Use Grand Central Dispach istead.
Since your Http method are of synchronous type ..Your UI will froze till response.
What you have done is in simple words tell the OS to perform these http requests before doing anything else.
On pressing home the system will wait..for a few seconds to receive a response..otherwise it will quit thee app. since it violates app guidelines..(you are blocking OS indefinitely)
The didEnterBackground will be called only if these requests will be finished or will not be called in the case when OS decides to terminate your app.
Related
I'm developing a chat-app for iOS that must use an existing server API. The way it works is pretty straightforward: the app checks every given interval whether there are new messages on the server and displays them, plus, it sends the server new messages that the user typed.
When the user starts 'multi-tasking' or presses the home button, my app will go to the background and therefore will not be able to check the server for new messages. The server will automatically assume that the user stopped the chat when a certain timeout has been reached.
Often, the user isn't aware of the fact that when the app is put to the background, it is unable to maintain the connection to the server and will stop the chat. I'm looking for a method that will notify the user of this behavior as soon as the app is put to the background.
My current idea is to notify the user when applicationWillResignActive and/or applicationDidEnterBackground is fired, but I wouldn't know in what way. Can it be done in a way that complies with Apple's guidelines?
I'm aware of the fact that the best solution would be a different overall design of the software (e.g., using push notifications and no server-side chat termination by timeouts), but in this case I can't change that.
I would continue running in the background and set an expiration handler block (called by the os when you app is REALLY killed) and there schedule a UILocalNotification
use
- (UIBackgroundTaskIdentifier)beginBackgroundTaskWithExpirationHandler:(void (^)(void))handler
I have an iPhone application like facebook for iPhone. My application must connect my server and read all message every two hours regularly. I have a thread to read all message but when the application is terminated the thread cannot work. Can the thread run undependently from main delegate or how can I find solution for this problem?
You cannot have your app do stuff in the background. There is an API to finish tasks like uploading a photo but even that will be killed after around 10 minutes.
But the Apple Push Notification Service seems like the most appropriate solution for your problem. Your server notifies the device that there is something new happening and you fetch the actual messages when the user opens the app.
edit: As of iOS 7 Apple implemented a feature where you can schedule running tasks to fetch data in the background. Those tasks are not guaranteed to run at any specific times. See the release notes for iOS 7 and the linked methods below:
Apps that regularly update their content by contacting a server can
register with the system and be launched periodically to retrieve that
content in the background. To register, include the UIBackgroundModes
key with the fetch value in your app’s Info.plist file. Then, when
your app is launched, call the setMinimumBackgroundFetchInterval:
method to determine how often it receives update messages. Finally,
you must also implement the
application:performFetchWithCompletionHandler: method in your app
delegate.
There is no solution.
Apple does not permit applications to run in the background unless they are of a specific type such as location or audio or voip or newstand (your app can continue to run for about 10 minutes after it was active if it uses shouldBeginBackgroundTaskWithExpirationHandler).
There is no workaround, many many other people have wondered how to do the same thing as yourself before, but there is no legitimate way. Your app cannot schedule any sort of periodic call home activity.
The only way your app can run once its gone into a suspended or terminated state is for the user to launch it, either explicitly or in reponse to a local notification or remote push notification.
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.
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.
I've just been reading this post on notifications being sent to apps running in the background :
Not getting didReceiveMemoryWarning when app is in the background
My question is that since an app in the background will not act on a didRecieveMemoryWarning until it enters the foreground again, what is the recommended way to free up memory in your app if it is running in the background when the memory notification is sent - or is this not possible ?
In iOS 4.0 and later, - (void)applicationDidEnterBackground:(UIApplication *)application 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.
If your app is running in the background (because it is, for example, a Voice over IP app that is allowed to run in the background), it will receive memory warning notifications in the same way as if it were running in the foreground, and you should deal with them accordingly.
However, if your app is suspended in the background, it won't receive memory warnings or other notifications. Your job is to free as much memory as possible before your app enters the background. Once you're in the background, you have no way to do anything anymore. The OS will decide whether to kill your app or not (without notifying you again) at its discretion.