A whole lot of trendy apps have a networking part to them. This could possibly be as a result of your app depends on a server solely for all information, otherwise you’re simply sending a few requests as a again up or to kick off some server aspect processing. When implementing networking, it’s not unusual for builders to test the community’s availability earlier than making a community request.
The reasoning behind such a test is that we are able to inform the person that their request will fail earlier than we even try to make the request.
Sound like good UX, proper?
The query is whether or not it actually is nice UX. On this weblog put up I’d wish to discover a few of the execs and cons {that a} person would possibly run into while you implement a community connectivity test with, for instance, NWPathMonitor.
A person’s connection can change at any time
Nothing is as inclined to vary as a person’s community connection. One second they is perhaps on WiFi, the subsequent they’re in an elevator with no connection, and simply moments later they’ll be on a quick 5G connection solely to modify to a a lot slower connection when their prepare enters an enormous tunnel.
When you’re stopping a person from initiating a community name once they momentarily don’t have a connection, which may appear extraordinarily bizarre to them. By the point your alert reveals as much as inform them there’s no connection, they could have already restored connection. And by the point the precise community name will get made the elevator door shut and … the community name nonetheless fails because of the person not being related to the web.
Because of altering circumstances, it’s usually really helpful that apps try a community name, whatever the person’s connection standing. In spite of everything, the standing can change at any time. So whilst you would possibly be capable of efficiently kick off a community name, there’s no assure you’re in a position to end the decision.
A significantly better person expertise is to simply strive the community name. If the decision fails because of a scarcity of web connection, URLSession will inform you about it, and you’ll inform the person accordingly.
Talking of URLSession… there are a number of methods during which URLSession will assist us deal with offline utilization of our app.
You might need a cached response
In case your app is used incessantly, and it shows comparatively static information, it’s possible that your server will embrace cache headers the place applicable. This can enable URLSession to regionally cache responses for sure requests which signifies that you don’t must go to the server for these particular requests.
Which means, when configured accurately, URLSession can serve sure requests with out an web connection.
In fact, that signifies that the person will need to have visited a particular URL earlier than, and the server should embrace the suitable cache headers in its response however when that’s all arrange accurately, URLSession will serve cached responses mechanically with out even letting you, the developer, know.
Your person is perhaps offline and a lot of the app nonetheless works advantageous with none work out of your finish.
This can solely work for requests the place the person fetches information from the server so actions like submitting a remark or making a purchase order in your app gained’t work, however that’s no cause to begin placing checks in place earlier than sending a POST request.
As I discussed within the earlier part, the connection standing can change at any time, and if URLSession wasn’t in a position to make the request it’ll inform you about it.
For conditions the place your person tries to provoke a request when there’s no lively connection (but) URLSession has one other trick up its sleeve; automated retries.
URLSession can retry community calls mechanically upon reconnecting
Generally your person will provoke actions that may stay related for a short while. Or, in different phrases, the person will do one thing (like sending an e mail) the place it’s utterly advantageous if URLSession can’t make the request now and as an alternative makes the request as quickly because the person is again on-line.
To allow this conduct you need to set the waitsForConnectivity in your URLSession’s configuration to true:
class APIClient {
let session: URLSession
init() {
let config = URLSessionConfiguration.default
config.waitsForConnectivity = true
self.session = URLSession(configuration: config)
}
func loadInformation() async throws -> Info {
let (information, response) = strive await session.information(from: someURL)
// ...
}Within the code above, I’ve created my very own URLSession occasion that’s configured to attend for connectivity if we try to make a community name when there’s no community accessible. Each time I make a request by this session whereas offline, the request won’t fail instantly. As an alternative, it stays pending till a community connection is established.
By default, the wait time for connectivity is a number of days. You’ll be able to change this to a extra affordable quantity like 60 seconds by setting timeoutIntervalForResource:
init() {
let config = URLSessionConfiguration.default
config.waitsForConnectivity = true
config.timeoutIntervalForResource = 60
self.session = URLSession(configuration: config)
}That approach a request will stay pending for 60 seconds earlier than giving up and failing with a community error.
If you wish to have some logic in your app to detect when URLSession is ready for connectivity, you’ll be able to implement a URLSessionTaskDelegate. The delegate’s urlSession(_:taskIsWaitingForConnectivity:) methodology can be referred to as at any time when a job is unable to make a request instantly.
Notice that ready for connectivity gained’t retry the request if the connection drops in the course of a knowledge switch. This selection solely applies to ready for a connection to begin the request.
In abstract
Dealing with offline eventualities ought to be a main concern for cell builders. A person’s connection standing can change rapidly, and incessantly. Some builders will “preflight” their requests and test whether or not a connection is out there earlier than trying to make a request with a view to save a person’s time and assets.
The most important draw back of doing that is that having a connection proper earlier than making a request doesn’t imply the connection is there when the request truly begins, and it doesn’t imply the connection can be there for the complete length of the request.
The really helpful method is to simply go forward and make the request and to deal with offline eventualities if / when a community name fails.
URLSession has built-in mechanisms like a cache and the power to attend for connections to supply information (if doable) when the person is offline, and it additionally has the built-in capacity to take a request, anticipate a connection to be accessible, after which begin the request mechanically.
The system does a fairly good job of serving to us assist and deal with offline eventualities in our apps, which signifies that checking for connections with utilities like NWPathMonitor normally finally ends up doing extra hurt than good.