Posts

Post not yet marked as solved
1 Replies
276 Views
So I'm getting some weird behavior when using an NSURLSession. Our app uses two separate sessions. And we aren't doing anything special when making them. This is it: let configuration = URLSessionConfiguration.default configuration.waitsForConnectivity = false configuration.timeoutIntervalForResource = 30 self.init(configuration: configuration) All we do is create data tasks using session.dataTask(with: request) After creating about 100+ data tasks and having them complete successfully with no problems, the session will hang for the full 30 seconds and return a -1001 "The request timed out." error. The next few tasks on this session will fail, and then all of a sudden the NSURLSession will start working again. Now the weird part is... since I have two NSURLSessions, only the one that has hit 100+ tasks times out. The other NSURLSession can still contact the same server URL and run tasks just fine. I did put this through the Network Instrument and one thing I did see is that up until the timeout happens the NSURLSession will use a single connection as expected. But after the 30s timeout and the recovery it looks like the NSURLSession decides behind the scenes to make a brand new connection and that's where the "recovery" comes from. Out server team swears this isn't them as other non-iOS clients hitting the same endpoint don't have this error. Any help? (Side note: I can fix this in my app by just making a new NSURLSession every 100 tasks, but that doesn't really help me understand what could be going wrong in the first place).
Posted Last updated
.
Post not yet marked as solved
2 Replies
657 Views
I am detecting "all touches in an application" by overriding the sendEvent method in my UIApplication subclass. As part of this I've included a click debouncer that discards old events if the main thread gets clogged up somehow. Apple's own documentation says to compare it to NSProccessInfo.systemUptime. https://developer.apple.com/documentation/uikit/uievent/1613790-timestamp?language=objc For an actual device this works just fine. But for the iOS simulator (iOS 15.4 simulator from Xcode 13.3) I'm getting some weird results where NSProcessInfo.systemUptime is 10's of thousands of seconds off. Anyone know what's causing this? -(void)sendEvent:(UIEvent *)event { NSTimeInterval eventTime = event.timestamp; // In simulator this ~= 6700 NSTimeInterval nowTime = NSProcessInfo.processInfo.systemUptime; // In simulator this ~= 280,000 // don't count old events, if possible (due to massive time discrepancies this if block is always hit in simulator if(nowTime - eventTime > 50) { [super sendEvent:event]; return; } // Do the actual thing I want to do ``` }
Posted Last updated
.