Is there an order for response, data, and error in URLSession delegates?

Question

SergioDCQ OP

Created May ’22

Replies 3

Boosts 0

Participants 3

_Posted this here, on Stackoverflow. But after 2+ weeks got only 10 views and no responses. _

I have my URLSession delegates working, but am curious about the order I get back response, data, and error.

Right now am testing purposeful errors on my server side, so I can check the response if it's not 200. If it's not, I do not need to process the data, etc.

So I could use a flag, but have to make sure that I'l always get response, data, and error in a specific order?

Does such an order exist?

extension UploadInv:  UIDocumentPickerDelegate, URLSessionDataDelegate,URLSessionTaskDelegate, URLSessionDelegate {

	// Error received
	func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) {
		if let err = error {
			print("Error: \(err.localizedDescription)")
		}
	}
	// Response received
	 func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive response: URLResponse, completionHandler: (URLSession.ResponseDisposition) -> Void) {
			completionHandler(URLSession.ResponseDisposition.allow)
		
		DispatchQueue.main.async { [self] in
			if let httpResponse = response as? HTTPURLResponse {
				if httpResponse.statusCode != 200 {
					DispatchQueue.main.async { [self] in
						self.myStatus.text = "Error \(String(httpResponse.statusCode))"
						myBackButt.isEnabled = true
					}
				}
			}
		}
	 }
	 
	// Data received
	 func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) {
			DispatchQueue.main.async { [self] in

Boost

Answer 1

Claude31 OP

May ’22

on Stackoverflow. But after 2+ weeks got only 10 views and no responses. _

You should have started on the forum… 😉

.

have to make sure that I'l always get response, data, and error in a specific order

I'm not sure you can expect a specific return order. What is the real problem if not ?

So you essentially want a synchronous behaviour.

You could use semaphores, and probably async/await to get a sequential call.

You may get some hints here (but different question): https://stackoverflow.com/questions/26784315/can-i-somehow-do-a-synchronous-http-request-via-nsurlsession-in-swift

Note: Quinn is cited in this SO post, he will certainly have a more elaborate answer.

0

Answer 2

Scott OP

May ’22

Well urlSession(_:task:didCompleteWithError:) always gets called last because it indicates the end of the task.

And urlSession(_:dataTask:didReceive:completionHandler:) (response headers) needs to get called before urlSession(_:dataTask:didReceive:) (body) because depending on how you call the completion handler, it can change how the body gets handled subsequently. And it’s just natural that your code would receive the headers before the body.

But for your situation, I think you can simplify by eliminating the response method entirely. Note the documentation says it’s intended for specific cases that don’t seem to apply here. Instead, just check the error and HTTP response code in the completion method, and then process the accumulated body data as needed.

(Or if you keep the response method, note you need to call the completion handler to tell the system what to do next. The documentation isn’t clear on whether you should call it synchronously or asynchronously. Seems to me you should call it synchronously since it seems to work like a function return value, but I may be missing something subtle there.)

1

Answer 3

Scott OP

May ’22

Also, a couple minor adjustments:

if let httpResponse = response as? HTTPURLResponse {

It’s generally safe to force the response as! HTTPURLResponse. If that optional binding were to actually fail, what then?

extension UploadInv: UIDocumentPickerDelegate, URLSessionDataDelegate, URLSessionTaskDelegate, URLSessionDelegate

You don’t need to list URLSessionDelegate or URLSessionTaskDelegate there, because URLSessionDataDelegate already extends them. I’m a little surprised there isn’t a compiler warning for that.

1