I want to use NSOperationQueue in my app and start downloading the images from server.
If my app goes to background or be terminated, will NSOperationQueue still continues downloading them?
No, the NSOperationQueue will not continue working when the app is moved to the background. You would need to explicitly action this by using the method beginBackgroundTaskWithExpirationHandler.
This is covered in Technical Note TN2277 - Networking and Multitasking
See also iOS App Programming Guide, specifically the section on App States and Multitasking.
As an aside, could I recommend that you instead use the AFNetworking library. It handles a lot of this functionality for you. Specifically, each class is a subclass of NSOperation.
Moreover, it already has an image downloader class in AFImageRequestOperation. So that should be very useful for you. AFImageRequestOperation is a subclass of AFURLConnectionOperation so you have access to the method setShouldExecuteAsBackgroundTaskWithExpirationHandler.
Of course, all this relates to multitasking so it is only available in iOS 4.0 and later.
Related
I have an app working just fine on iOS 9 with a Custom NSURLProtocol implemented with NSURLSession. All the requests executed by the client are done with NSURLSession as well and each sessionConfiguration is registering to the protocol before executing the request.
I have an issue with iOS 8 that I don't have with iOS 9. With iOS8 the Custom NSURLProtocol is performing that request non stop, basically an infinite loop of the same request. canInitWithRequest: in the custom protocol gets called way more on iOS 8 than on iOS 9 which basically drives the method startLoading to get called and fire the request after some header modifications that my protocol is supposed to perform.
Is there a known issue with iOS8 where NSURLProtocols and NSURLSession don't behave as expected?
I'm not aware of any problems like that, no.
This sounds like your protocol is either:
Failing to detect its own header modifications for some reason
Failing to make the modifications for some reason
Failing to return NO when your protocol is asked if it should handle a request that already contains the modified headers
Be sure that you are using a header field for the purpose of detecting whether to handle the request. There's no guarantee that the specific NSURLRequest object that you pass down into the machinery will come back to you. I'm not even sure I would trust propertyForKey:inRequest:, but that might make me too paranoid.
Critically, don't ever subclass NSURLRequest when working with NSURLSession. In iOS 9, it almost works. The farther back you get, the more broken the behavior, until by iOS 7 you're pretty much relegated to using NSURLConnection. :-)
I want to upload a file to a server using NSURLSession.
Cases Are:
1. It should resume uploading a file to the server from where it stopped because of app crash.
2. It should handle background upload as well.
Try AFNetworking Library to upload image asynchronously.You can find a brief example in this thread.
You should use background NSURLSession. If your app crashed or user left the app while upload was in progress, with a background NSURLSession the upload would continue seamlessly in the background. When the upload is done, your app will be notified of this via the delegate (and if your app wasn't alive at the time the download finished, it will be started in a background mode, at which point you can do whatever cleanup you need).
So create NSURLSessionConfiguration with backgroundSessionConfigurationWithIdentifier, and then instantiate a NSURLSession with that configuration.
There are a few caveats:
You cannot use completion handler pattern. You have to use delegate-based implementation.
You have to implement handleEventsForBackgroundURLSession in the app delegate, capturing the completionHandler it passes you and also instantiate the background session again. Likewise, in your NSURLSession delegate methods, you have to implement URLSessionDidFinishEventsForBackgroundURLSession, which will call the saved completion handler.
For more information, see Background Task Considerations in URL Session Programming Guide, see a section of the same name (but different text) in the NSURLSession class reference, or see the WWDC 2013 What's New in Foundation Networking, where Apple first introduced us to background sessions.
I would like to know how it is possible to continue a async NSURLConnection, which has been started in the foreground, when the app will be terminated.
Currently I am starting a NSURLConnection when the app goes in the background. This works fine as long as the user is slower than the connection, when he wants to terminate the app. But when the user is quicker than it, the connection can't be established.
Here is my code:
// AppDelegate.m
- (void)applicationDidEnterBackground:(UIApplication *)application
{
AnObject *newObject = [[AnObject alloc] init];
[newObject InactiveApp];
}
// AnObject.m
- (void)InactiveApp
{
self.backgroundTaskID = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:NULL];
// setting up the NSURLRequest
// [...]
dispatch_async(dispatch_get_main_queue(), ^
{
[NSURLConnection connectionWithRequest:request delegate:self];
});
}
// delegate functions, endBackgroundTask-closing, etc. is following
Unfortunately this is not working and I would like to know whether someone knows another way to fix it. There has to be a way which is similar like Snapchat or WhatsApp is doing it, because when you write an message and terminate the app right after pressing send, the message will be delivered.
The only way I could imagine is to do it with a background fetch but I think that is not the best solution, due to the fact that I just want to make one single connection when the App is send to the background.
I agree with Andy, that you should pursue NSURLSession and a background NSURLSessionConfiguration. See downloading content in the background section of the App Programming Guide for iOS: Background Execution.
By the way, the idea in your question will work fine (especially if you need support for iOS versions prior to 7.0, where NSURLSession and its background sessions are not available). Two observations regarding your code snippet:
The way you've written it, would appear that your AnObject would be prematurely deallocated when it falls out of scope and your app would therefore fail when it tried to call the delegate methods. Make sure to maintain a strong reference to AnObject.
Don't forget to call endBackgroundTask when the download is done. Likewise (and more subtly), the timeout handler should end the background task, too. See the Executing Finite Length Task section of the aforementioned App Programming Guide.
By the way, you mention requests continuing after the app is terminated. If a user manually terminates an app, that kills both background tasks contemplated in your question as well as background NSURLSession tasks. These are intended to gracefully handle continuing tasks if the app leaves foreground, not if the user manually terminates the app. The NSURLSession approach gracefully handles terminations due to memory pressure, but not manual termination.
Encountered a very weird problem, using simple AFNetworking downloading operation, even tried with simple NSURLConnection operation, connection fails if you keep your app running, and lock screen and then unlock. Works absolutely fine in background though.
Any one encountered similar problem with NSURLConnection want to share some solution?
Thanks.
It looks like an iOS bug. Weird, but lock screen action affects NSURLSession somehow, so that it stops working and returns NSURLErrorNetworkConnectionLost. So in my app I gave up using shared session. I either use a new session object for every request or (if I need to maintain one session constantly) recreate it every time the screen gets unlocked. And it works. For users of AFNetworking or any other third party library working on top of NSURLSession the situation is harder, of course. You'll need to correct the code of the library, which is definitely not a good thing, but I think there's no other choice
Very helpful Andrey Chernukha,
In my case, figured out that you don't necessary need to recreate new session every time.
I ended up using array to save running NSURLSessionDataTasks and after phone is unlocked resume them.
Steps:
I created array NSMutableArray *dataTasksToResume
In - (void)applicationWillResignActive:(UIApplication *)application I saved all tasks to dataTasksToResume array
Cancel all running NSURLSessionDataTasks
In - (void)applicationDidBecomeActive:(UIApplication *)application get all tasks from array and resuming them (re-creating them)
Enjoy!
Hope it helps.
I have a question about AFNetworking 2 and background downloads/uploads thanks to the new iOS7 NSURLSession background requests
Is this automatically handled by my AFHTTPRequestOperationManager ? Does it automatically set my requests'session to background mode?
I saw that the AFURLSessionManager Has a setDidFinishEventsForBackgroundURLSessionBlock Method but I wonder if everything is automatic?
If my app is killed or suspended, will requests keep on going? How can I get a callback when my app is relaunched?
Thanks a lot for your help!
AFHTTPRequestOperationManager uses the old NSURLConnection so that doesn't facilitate background downloading.
AFURLSessionManager uses NSURLSession under the hood so that does. I think you still need to configure the NSURLSession appropriately.
"The NSURLSession class supports background transfers while your app is suspended. Background transfers are provided only by sessions created using a background session configuration object (as returned by a call to backgroundSessionConfiguration:)."
Suggested reading:URL Loading System