0

I'm working on an app whose requests to the server can end up lasting quite some time, think 10 - 30 minutes. I think it's pretty safe to say that undoubtably, the user will go into the background during the request's execution.

I've got this to properly work using Background Tasks, but as they give you only 3 minutes, the request will snap; not something that is allowed in my use-cases.

I've read up on background modes and possibly using Download and Upload tasks, but my use-case does not conform to any of them. It's a large JSON request/response.

Something that crossed my mind was to maybe save the JSON to a file and send the file itself. That should comply with the background download that's supported by NSURLSession.

Does anyone know of another way? So I don't have to change the request/response structure.

Thanks in advance!

D6mi
  • 611
  • 7
  • 16
  • 1
    what on earth are you doing that its taking 30 mins to download Watchdog would not let that happen once app goes background, So i would suggest you to change your DB and structure or response. – Saheb Roy Jun 07 '16 at 10:11
  • The 30 minutes thing can be applied to uploads, downloads usually last much shorter. The uploads can get that long because it's an offline app and users can create new stuff that needs to be synced to the server - sometimes lasting up to 30 minutes. – D6mi Jun 07 '16 at 10:19
  • 1
    so you should be breaking that up and sending smaller parts - this is a mobile device and it's your job to design it in an appropriate and sympathetic manner... – Wain Jun 07 '16 at 10:20
  • I might be missing something here, but wouldn't separating the large request into smaller, separate ones even further the length of the whole process? I was of the assumption that I have a total of 3 minutes per process - is it 3 minutes per background task? – D6mi Jun 07 '16 at 11:31
  • perhaps, it will increase overheads, but it makes the whole process more manageable. don't rely on a set amount of background time, the OS gets to choose how much you get. – Wain Jun 07 '16 at 11:46
  • It would indeed make it more manageable, but, unfortunately, it wouldn't solve the issue of the user going to the background and the expiration handler firing while the request(s) is in progress. Nevertheless, thanks for your input, much appreciated! :) – D6mi Jun 07 '16 at 11:50

1 Answers1

1

This kind of situation should be handled along the lines of sending a 'job' request, which returns basically immediately with a token and simply schedules / starts the activity on the server. The app can then request the result for that token to determine if the job is complete and to get the data.

You wouldn't check in the background necessarily, or not periodically anyway - you'd check when the app was opened or perhaps using background refresh.

A better way would be to have the server send a push notification to the user / device, possibly a content-available notification, so the app doesn't need to make a request until it knows the data is ready.

Wain
  • 118,658
  • 15
  • 128
  • 151
  • I really dig the idea, thanks! Currently, we have some constraints that prevent us from implementing something like this, but it seems this suggestion will hang around with us, with a possible implementation somewhere down the line. – D6mi Jun 07 '16 at 11:32