Post

Replies

Boosts

Views

Activity

Reply to Receiving "The request timed out." when using NSURLSession
Hi Joachim, thank you very much for the detailed info. I have additional questions for you: timeoutInterval for NSURLRequest should be the same of timeoutIntervalForRequest. If the former has strict value than the latter, should NSURLSession honor its value? what is the real meaning of timeoutInterval? Is it correct to represent it as the amount of time between packets? what should be the correct way to handle tasks when the application goes in background? I would not use a background session. why subsequent requests after the first failing one are failing too?
Dec ’21
Reply to Receiving "The request timed out." when using NSURLSession
Hi Joachim, I really appreciate your response. Thank you very much! Below my replies / notes: Regarding tasks 179 and 172, I can confirm they are not sent to the same server. I haven't included them for privacy reasons. But for sure I could share the full trace with you privately. About requests in general I cannot find a way to know where they were made using the network or handled by the local cache. Can you point me in the right direction in order to find such an information? Finally, concerning the latest sentence I do not have clear what you mean with "take a closer look at the domain track for these tasks". Since you are confirming those issues could be due to background state, I've started to implement a way to handle this using beginBackgroundTaskWithName:expirationHandler: and endBackgroundTask:. In particular, when I need to perform a request, I create both a new background task identifier and session data task like the following. // tell the system the work could continue in background __block UIBackgroundTaskIdentifier backgroundTaskIdentifier = UIBackgroundTaskInvalid; backgroundTaskIdentifier = [[UIApplication sharedApplication] beginBackgroundTaskWithName:taskName expirationHandler:^{ [self.internalLock lock]; for (NSURLSessionDataTask* dataTask in self.dataTasks) { [dataTask cancel]; } if ([self.dataTasks count] > 0) { // manage failure here? } [self.dataTasks removeAllObjects]; [self.internalLock unlock]; cleanupBackgroundTaskIdentifier(backgroundTaskIdentifier); }]; // create a data task to perform the request __block NSURLSessionDataTask *task; task = [self.urlSession dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) { // handling the result here cleanupBackgroundTaskIdentifier(backgroundTaskIdentifier); sendResult(result); [self.internalLock lock]; [self.dataTasks removeObject:task]; [self.internalLock unlock]; }]; [self.internalLock lock]; [self.dataTasks addObject:task]; [self.internalLock unlock]; task.taskDescription = taskName; [task resume]; where void(^cleanupBackgroundTaskIdentifier)(UIBackgroundTaskIdentifier) = ^void(UIBackgroundTaskIdentifier backgroundTaskIdentifier) { [[UIApplication sharedApplication] endBackgroundTask:backgroundTaskIdentifier]; backgroundTaskIdentifier = UIBackgroundTaskInvalid; }; It's a very old legacy code so I'm not sure this is the right way to handle such a scenario.
Dec ’21
Reply to Receiving "The request timed out." when using NSURLSession
Hi Joachim, thank you very much for the detailed info. I have additional questions for you: timeoutInterval for NSURLRequest should be the same of timeoutIntervalForRequest. If the former has strict value than the latter, should NSURLSession honor its value? what is the real meaning of timeoutInterval? Is it correct to represent it as the amount of time between packets? what should be the correct way to handle tasks when the application goes in background? I would not use a background session. why subsequent requests after the first failing one are failing too?
Replies
Boosts
Views
Activity
Dec ’21
Reply to Receiving "The request timed out." when using NSURLSession
Hi Joachim, I really appreciate your response. Thank you very much! Below my replies / notes: Regarding tasks 179 and 172, I can confirm they are not sent to the same server. I haven't included them for privacy reasons. But for sure I could share the full trace with you privately. About requests in general I cannot find a way to know where they were made using the network or handled by the local cache. Can you point me in the right direction in order to find such an information? Finally, concerning the latest sentence I do not have clear what you mean with "take a closer look at the domain track for these tasks". Since you are confirming those issues could be due to background state, I've started to implement a way to handle this using beginBackgroundTaskWithName:expirationHandler: and endBackgroundTask:. In particular, when I need to perform a request, I create both a new background task identifier and session data task like the following. // tell the system the work could continue in background __block UIBackgroundTaskIdentifier backgroundTaskIdentifier = UIBackgroundTaskInvalid; backgroundTaskIdentifier = [[UIApplication sharedApplication] beginBackgroundTaskWithName:taskName expirationHandler:^{ [self.internalLock lock]; for (NSURLSessionDataTask* dataTask in self.dataTasks) { [dataTask cancel]; } if ([self.dataTasks count] > 0) { // manage failure here? } [self.dataTasks removeAllObjects]; [self.internalLock unlock]; cleanupBackgroundTaskIdentifier(backgroundTaskIdentifier); }]; // create a data task to perform the request __block NSURLSessionDataTask *task; task = [self.urlSession dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) { // handling the result here cleanupBackgroundTaskIdentifier(backgroundTaskIdentifier); sendResult(result); [self.internalLock lock]; [self.dataTasks removeObject:task]; [self.internalLock unlock]; }]; [self.internalLock lock]; [self.dataTasks addObject:task]; [self.internalLock unlock]; task.taskDescription = taskName; [task resume]; where void(^cleanupBackgroundTaskIdentifier)(UIBackgroundTaskIdentifier) = ^void(UIBackgroundTaskIdentifier backgroundTaskIdentifier) { [[UIApplication sharedApplication] endBackgroundTask:backgroundTaskIdentifier]; backgroundTaskIdentifier = UIBackgroundTaskInvalid; }; It's a very old legacy code so I'm not sure this is the right way to handle such a scenario.
Replies
Boosts
Views
Activity
Dec ’21
Reply to [Xcode] Meaning of flags in Network Instruments trace
Hi Joachim, thank you very for your answer. This question relates to https://developer.apple.com/forums/thread/696762?page=1#698464022 since I was trying to verify the problem is related to background state. For sure, as you described in the other thread, I could take advance of Time Profiler. It could take me some time to replicate.
Replies
Boosts
Views
Activity
Dec ’21