URLConnection best practices on bad/slow connections


I wanted to have your advice on how to manage slow/bad connections. Data transferred are mainly JSON and binaries (up and down) using URLConnection in async mode. We manage the API so any modification is possible.

Some of our customers are using bad connections (WiFi or even 4/5G box). We already compressed some data using zstd library that can shrink greatly JSON responses with the standard compression level.

But I had some questions on how to manage these events (slow connection, drop of connections, packet loss, etc) ?

  • Do I have to create a kind of retry property for each request sent that will retry the request everytime it fails?
  • Should I prevent the user from closing the current window when the request is still ongoing.
  • How about files that got interrupted, is there any way to stop a download/upload and restart it.
  • How do you tell the user all these things (requests ongoing, requests failed, try again, etc) ?

Thank you,


Hi Julien,

How big is the data being transferred?

I am using Cloudflare to manage my domain and DNS. Most files are cached with Cloudflare and even some API requests which I know are static. This reduces latency as the server is located in Europe but users could be anywhere in the world.
I have also activated Cloudflare Argo smart routing which will find the best route from the user to the server.
I also enabled Brotli compression in Cloudflare which apparently is more efficient than gzip and deflate.

When sending data to my API, I will either retry or display an error message.

When getting data from the API, this is how I manage failures in my apps:

  • User action: I do not retry. Display an error message with a Retry button
  • Background action such as getting the app configuration, retry 5 times. First retry after 500ms, then 1 second, then 2s, then 4s, 8s.

It really is up to you to decide if retry is necessary.

The best way I have found to manage retries is to create a class named URLConnectionRequest.
It holds everything needed to replicate a URLConnection (Sending method, Headers, url, postdata…)
I made a subclass of URLConnection that takes a request as a parameter to set everything in the URLConnection and make the async call.

If this is a desktop app, you might also want to create your own form of caching, with a SQLite database. Static API calls would then be cached for 1, 10, 30 days and make loading of the app faster.
I have such a caching class that I can share if you need.


thank you for the answer.

I do not know about the cached service because every customer got it’s own instance of the API hosted on a cloud provider or on-premise. We discovered that even with on-premise servers, some companies have a really bad network…

The data being transfered about are about some Ko (< 1 mo) for JSONs and for files it can be up some MOs (we are mainly transferring docx documents and related Office format pptx and xlsx).

I like the idea about showing an error message with the Retry button.

I did create a specific class for all that but do you use the same instance to start the request again? (are you calling disconnect before or no).

I need to add parameters to store the postdata/headers because I do not know if I can retrieves them from the original request in the response event.

It is indeed a desktop app.

Thank you

I always create a new connection.

From the docs:

A disconnected socket is not set to Nil, but is no longer in a useful state. You should create a new socket rather than attempting to re-use a disconnected socket.

Oh… that’s bad. Won’t be able to use Cloudflare for that.