nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Background Session for NSURLSession in iOS

Mark R.5

I am after a little advice on background/foreground session usage. The documentation states that by default, background sessions are used for uploads and download. As I understand it, this means that the transfer can complete even if the app is no longer running. You can optionally use foreground sessions instead, but then you lose the ability to transfer when the app is suspended or quit.

In my case, I am only uploading/downloading small files (as part of a data syncing strategy). This is mainly done in the foreground when the user adds data to the app. If the user comes out of the app, then the app asks for more time to complete any data transfers (using the beginBackgroundTaskWithName app delegate method). This is typically sufficient for the small size of the data involved.

So would I be better off setting sessions to run in the foreground? The only downside I can see if that if the app is quit or the network connection is lost, then the transfers will not complete. However the syncing code is designed to check for incomplete transfers and try again when the app is restarted, which should mitigate against this.

I am a little wary of background transfers since I am not sure how it behaves if the transfer is completed when the app is not running (and therefore my syncing code it not there to control it)...

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Hi Mark, the SDK does give you the choice of using foreground or background sessions, and it sounds like you have a good understanding of the difference already. This is a bit outside the scope of Dropbox API support though, so I'm afraid I can't offer much insight myself. Hopefully there's someone with more experience with iOS development that can offer some advice. (Or, you may want to ask in a more iOS-specific forum, such as Apple's forums.)

Mark R.5

Hi Greg,

I think part of my query does actually relate directly to the framework. If you read the 'Background Transfer Considerations' section in Apple's documentation:

URL Session Programming Guide

then it explains what an app should do in the event that a transfer completes when the app is not running. Specifically:

----------------------------------

In iOS, when a background transfer completes or requires credentials, if your app is no longer running, iOS automatically relaunches your app in the background and calls the <A class="urlLink" href="https://developer.apple.com/reference/uikit/uiapplicationdelegate/1622941-application" target="_self" rel="nofollow noopener noreferrer">application:handleEventsForBackgroundURLSession:completionHandler:</A> method on your app’s UIApplicationDelegate object. This call provides the identifier of the session that caused your app to be launched. Your app should store that completion handler, create a background configuration object with the same identifier, and create a session with that configuration object. The new session is automatically reassociated with ongoing background activity. Later, when the session finishes the last background download task, it sends the session delegate a <A class="urlLink" href="https://developer.apple.com/reference/foundation/urlsessiondelegate/1617185-urlsessiondidfinishevents" target="_self" rel="nofollow noopener noreferrer">URLSessionDidFinishEventsForBackgroundURLSession:</A> message. In that delegate method, call the previously stored completion handler on the main thread so that the operating system knows that it is safe to suspend your app again.

In both iOS and OS X, when the user relaunches your app, your app should immediately create background configuration objects with the same identifiers as any sessions that had outstanding tasks when your app was last running, then create a session for each of those configuration objects. These new sessions are similarly automatically reassociated with ongoing background activity.

------------------------------------

Since the Dropbox framework manages the sessions, then does it also deal with the fiddling around described above or is that left up to the app?

Greg-DB

I'm checking in with the team to get some information on the specifics of this in the Dropbox SDK. Thanks in advance for your patience.

Stephen C.14

Hi Mark, sorry for the delay here. Unfortunately, the SDK doesn't expose an interface for implementing this session re-attachment behavior.

I'm no expert in this behavior, but if I recall, after sesion reattachment, you need to resupply a response handler to handle the upload or download that completed while your app was not running.

There's no way to do that other than to handwrite some logic in `application(_:handleEventsForBackgroundURLSession:completionHandler:)`.

You'd have to maintain some sort of map between request id and response handler there, and reinstall the handler accordingly. This would complicate the SDK interface considerably.

For that reason, the SDK simply chooses not to handle the case where the application is killed.