Could not find any documentation on this instance variable.
Is it related at all to being able to handle the response to a network request even when the app has been moved to the background?
From the SDK's NSURLSession class comments:
"Enable extended background idle mode for any tcp sockets created. Enabling this mode asks the system to keep the socket open and delay reclaiming it when the process moves to the background."
So, it looks like this is aimed at prolonging a network connection that is active when the user sends the app from the foreground to the background and it enters suspended state.
Related
We are building an iOS iPhone app that needs to check-in with a server on a 12 hour basis. This is needed to let the server know that the app is still using it's service on the server. To our understanding this is possible when the app is in background state (not showing on the foreground) via backgound fetch or remote notifications.
But this is not possbile when the app is not running or terminated, when the app is in these states then there is no way to initiate communication with a server. Is this statement corret? Is it possible initiate the communication after a device bootup, is it then possible to send a small keep alive message to te sever?
The background fetch and responding to remote notifcations is not possible in the not running and termenating states(?), so we cannot use these mecahnisms for this purpose. If that is the case are there any other solutions that we can try? Or is it just not possible?
We looked at many sources on the internet but some say that it is possible and others say it is not.
You might want to take a look at the Silent Push Notifications. Here is the thing, if the app is in background mode or suspended state, you will be fine. If the app was killed by the user, you have a problem.
You can always send a silent push notification, and wait for a service call made from the device to your service. If there is a response, it means the app was in background or suspended, and then you can go ahead and do whatever you need to do. If no request is made, it means that app was killed. Then you might want a sent a non silent push letting the user of that device know that he needs to launch the app or something like that. I don't know how you are going to work around it, but that could be a possibility.
I would tell you to take a look at NSURLSession and Background NSURLSessionConfiguration as well, but you will run into the same issue. If the user manually terminates the app, you need to find a work around to set up that connection to the server, and that will imply the user to somehow launch your application.
Certain kinds of iOS apps are allowed to periodically run in the background. For a background-audio, bluetooth-central, or location-fencing app (as listed in the app's capabilities plist), can the iOS app open a BSD network socket (assuming the device has appropriate network connectivity) when given time in the background?
If so, what kind of problems might one encounter when doing this (errors, timeouts, etc.) other than those that an app would see when networking in the foreground?
I believe other than the services you mentioned the only other background task you are allowed is via the NSURLSession class. Using the NSUrlSession class you are allowed to make HTTP requests to a web server while the application is in the background.
For example, you're app could monitor for significant location changes in the background, and during the location change event you could send the GPS coordinates to the web sever via an NSURLSession.
However, from what I understand this is the ONLY networking you're allowed todo while the application is in the background without hacks. Therefore, I do not believe it is possible to open a BSD socket connection while you're app is in the background.
We have an game that creates a player lobby using sockets. When the player creates a lobby, a game is created on our server. Unfortunately if the user switches our app away with the Apple button, another user may join the game and the game will start with just one player active. So we want to send a message to our server via a socket when the app transitions to the background to close the lobby, stopping others joining.
But we can't. The sockets get frozen on entering background mode. Even if we keep the app alive a while using beginBackgroundTaskWithExpirationHandler, no socket activity works.
VOIP is not an option, as the title is not VOIP related and will get bounced immediately from Apple submission.
Any one got any non-VOIP related ideas?
Many thanks,
Steve.
I think what you want to do is to let the server know that this user is off-line when touching the Apple Home button.
I am using GCDAsyncSocket, but other ways may be similar.
What I'm doing is
Add observer on UIApplicationDidEnterBackgroundNotification.
When application enter background then call socket disconnect. The server will know that you are off-line.
I know this is a little late for your answer, but could be helpful for others.
After reading the Apple documentation about the background download with the new iOS7 api (NSURLSession), I'm a bit disappointed. I was sure that Apple was managing the pause/resume over the network availability in the background (or provide an option to do so) but no…
So reading the documentation, this is what we've got:
https://developer.apple.com/library/ios/documentation/cocoa/Conceptual/URLLoadingSystem/NSURLSessionConcepts/NSURLSessionConcepts.html
When any task completes, the NSURLSession object calls the
delegate’s URLSession:task:didCompleteWithError: method with either an
error object, or nil if the task completed successfully.
If the task is a resumable download task, the NSError object’s userInfo dictionary
contains a value for the NSURLSessionDownloadTaskResumeData key. Your
app should use reachability APIs to determine when to retry, and
should then call downloadTaskWithResumeData: or
downloadTaskWithResumeData:completionHandler: to create a new download
task to continue that download. Go to step 3 (creating and resuming
task objects).
So far I understand the solution, but my question is: What architecture is the best to handle the loss of the network and resume downloading in the background?
On my side I'm using reachability and each time the network is available, I resume all tasks (referenced over a NSArray when creating), and suspends them when network is lost. This works well in foreground but for the background I need help on the following points:
If my app has no connectivity in foreground, if I go to the background without connectivity all my tasks remains suspended and won't came back if network is available…
Losing network in background, stop all my downloads/tasks.
Scenario:
In foreground, I start downloading my tasks
I go to background and after 10s switch to "aireplan mode"
All my tasks got an error. So in the method URLSession:task:didCompleteWithError: I resume them using
downloadTaskWithResumeData or if I can't (because some have not
enough resume data) I'm creating a new task without resume-ing it (except if network is back at that time).
Then I put the wifi up
As I'm still in background I cannot trigger a "resume" when network is back without launching the application…
How do I address these points? Have I missed something?
As I'm still in background I cannot trigger a "resume" when network is back without launching the application…
you can use "background fetch"，when the app is launched by fetch，then you can check network and resume the download task.
You should create the NSURLSession with background configurations, then your task is sent to a background demon and your app get called when it is completed.
Implementing:
application:handleEventsForBackgroundURLSession:completionHandler:
in the app delegate - without calling the completionHandler - causes the app to hang around in the background after the device loses its connection whilst suspended. That way, the app can still listen to reachability notifications and restart the download when a network connection becomes available once again. However, this is a pretty dodgy approach and may not pass Apple's app store submission guidelines. Additionally, this approach isn't much help when the connection is lost while the app is in the foreground and the connection regained whilst the app is suspended.
In the end I did the following:
Made use of the application:handleEventsForBackgroundURLSession:completionHandler: notification to pause my downloads in the background.
Made use of the intermittent background fetch notification (ie. application:performFetchWithCompletionHandler:completionHandler) to check connection status and restart any paused downloads. (hat-tip #gugupluto)
This still doesn't provide optimal download performance and may lead users to wonder why their "background download" hasn't finished once they reopen the app, but it seems to be the best we can hope for from Apple for now.
I'm doing a VOIP project on iPhone. I have the problem to keep the socket alive.
I already configured one socket for VOIP usage, and set kCFStreamNetworkServiceTypeVoIP for CFReadStreamRef and CFWriteStreamRef.
When my app runs in the foreground and I don't do any action, after 1 minute iPhone will sleep, black screen. My socket is still connected to the server.
But when my app runs in the foreground I press home button, and don't do any action, about 1 minute iPhone will sleep, then my socket disconnects from server.
Please help me.
First, have you read Tips for Developing a VoIP App? From your description, it sounds like you haven't set UIBackgroundModes to voip. You also likely will need to configure a keep alive handler.