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. :-)
Related
I am wondering how the lifetime of a LAContext instance from the LocalAuthentication framework looks like in iOS 8.
In iOS 9 and later, there is the invalidate method to manually invalidate the current context. If I am not using that method, the LAContext instance will still be active and store the state of the evaluation. One could say that I could simply nil/release it after usage, but I need the instance across the functionality to do additional things like validation of the availability of it and to enable the invalidate method at a different point of the VC. Does this also happen on iOS 8? I would ask Apple, because the docs do not clarify this, but I wanted to reach out for some more thoughts beforehand.
Thanks everyone!
Answer from Apple: On iOS 8, it behaves like on iOS 9 and later without calling invalidate, so in order to terminate it after using it, the developer can nil it and the instance will be released.
I'm trying to find a way to prevent NSURLSession from caching responses (in Simulator) by using approach from these questions:
Prevent NSURLSession from caching responses
NSURLCache does not clear stored responses in iOS8
I don't want to use approach from this question:
Clear NSURLSession Cache
which is using ephemeralSessionConfiguration call to NSURLSessionConfiguration when setting up a new NSURLSession instance.
I just want to not cache requests, in worst case clear the cache when application resigns active.
With call [NSURLCache sharedURLCache] removeAllCachedResponses] in applicationWillResignActive execution in app delegate i still get Cache.db present and full of cached responses/requests in respective iOS Simulator cache on disk.
Before that, I changed all my NSURLSessionConfiguration cache policy to NSURLRequestReloadIgnoringCacheData NSURLRequestReloadIgnoringLocalCacheData
NSURLRequestReloadIgnoringLocalAndRemoteCacheData
(tested all three cases, the last one is probably not implemented) instances (and effectively ALL cache policies). Isn't changing cache policy supposed to result in not caching server responses and requests on simulator? Does it depends on storage policy in response headers?
I'm using iOS 9.3 and iOS 10.1 Simulators for iPhone and v. 10 of iOS SDK. Project is in Objective C, maybe full Swift project would behave differently?
Is this behavior different for simulators and with devices? Why is this happening, is there a solution different from using dependency (can't fall onto one right now for some reason).
I had a similar issue and I was able to fix this by setting the properties- URLCache and requestCachePolicy on NSURLSessionConfiguration to nil and NSURLRequestReloadIgnoringCacheData respectively.
Also, you can try setting the cachePolicy property on NSMutableURLRequest to NSURLRequestReloadIgnoringCacheData.
So the rude solution is ... drop the Cache.db file on app resigning. I assume on the simulator you should be able to?!
But, did you try the ephemeralSessionConfiguration? Because Apples header doc says:
* An ephemeral session has no persistent disk storage for cookies,
* cache or credentials.
So I have implemented my own NSURLProtocol sub class. I registered it when app launches.
I tried to print all requests in canInitWithRequest:, however while running, it's not getting all the requests, just a few domains.
Is there anything I should notice or be careful? Any possible reasons? What did I miss? Thank in advance.
It kind of depends on how you registered it. You can register it for use with NSURLConnection (and, IIRC, the shared NSURLSession), or you can register it for use with other NSURLSessions individually. If a request happens in a session that your protocol isn't registered in, your protocol won't see it.
I am using NSURLConnection for accessing webservices.
I am getting proper response in iOS 4.3 but If I run the same code in iOS5 I am getting NULL response.
What are the changes do I need to make to the existing NSURLConnection delegates to work successfully.
I have implemented NSURLConnectionDataDelegate & NSURLConnectionDelegate. Even then its not working.
Thanks in advance.
You have some changes with NSURLConnection class in iOS 5 (some delegate methods are now deprecated).
You can find a good post about it here : NSUrlConnection Class Changes
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.