3

Background

  1. A user of my app does something with my app, that schedules asynchronous AFNetworking HTTP request with some completion handler.

  2. Then, without a delay, user of my app goes to a home screen so my app enters to a background.

A network is very slow, so my app will receive response after 20 seconds, which means that network response will reach my app when it is in background state.

Questions

  1. What will happen to this network request and specifically to its completion handler?

  2. I know, that dispatch_async retains all the stuff passed to its block, so I expect a completion handler of my response to be executed at some point, is it so?

P.S.

I don't mean asynchronous HTTP requests intended to run when application is in background, I mean regular asynchronous HTTP requests that are performed when app is in normal state.

UPDATE 1

I did find a partial answer in the related topic: What happens to tasks in dispatch queues when an app enters inactive/background/suspended states in iOS?.

I'll quote it shortly:

When an app is suspended, the entire process is frozen... tasks existing in pre-suspension GCD queues do not disappear upon resumption. They never went away; they were only paused.

The most simple test I tried is the following:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    double delayInSeconds = 10.0;
    dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC));
    dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
        NSLog(@"I am alive!");
    });
    return YES;
}

If I launch this app, then go to background immediatedly, then wait enough (so 10s can pass), then activate it - I see how NSLog message appears in a console.

What I still don't understand is how this applied to delayed HTTP responses - if an app is frozen - how they are handled then? If someone is aware of how app's transition to background affects how it will handle delayed HTTP responses, please do share your knowledge!

Community
  • 1
  • 1
Stanislav Pankevich
  • 11,044
  • 8
  • 69
  • 129
  • Did you try to test that? It's quite simple to check – hybridcattt Nov 12 '13 at 13:19
  • I will test it, and beside I just want to see someone else experience on this question. Could you provide anything on it? – Stanislav Pankevich Nov 12 '13 at 15:26
  • In my app I don't start any background tasks as mentioned in the answer below, and code execution totally freezes at the exact moment when app goes to background, and resumes from the same point when it comes to foreground. This includes all core data processing, afnetworking callbacks, etc – hybridcattt Nov 12 '13 at 15:30

1 Answers1

4

You have to ask the OS for time in order to continue tasks in the background.

From Apple docs:

Any time before it is suspended, an application can call the beginBackgroundTaskWithExpirationHandler: method to ask the system for extra time to complete some long-running task in the background. If the request is granted, and if the application goes into the background while the task is in progress, the system lets the application run for an additional amount of time instead of suspending it

In general the answer to your question is yes, the completion handler will be called in the background as long as the job does not need more than 10 minutes to complete while the app is in the background.

Nikos M.
  • 13,685
  • 4
  • 47
  • 61
  • Thanks for the answer. I am aware about `beginBackgroundTaskWithExpirationHandler:` - I want to know about the defaults! Next - 10 minutes? - Can you show official docs mentioning 10 minutes? – Stanislav Pankevich Nov 12 '13 at 15:24
  • I was not able to find the word 10 minutes any more (docs are updated for iOS 7) but here: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/iphoneappprogrammingguide.pdf it is mentioned: "Do minimal work while running in the background. The execution time given to background apps is more constrained than the amount of time given to the foreground app. Apps that spend too much time executing in the background can be throttled back by the system or terminated." – Nikos M. Nov 12 '13 at 15:33