Lots of fashionable apps have a networking element to them. This might be as a result of your app depends on a server completely for all information, otherwise you’re simply sending a few requests as a again up or to kick off some server facet processing. When implementing networking, it’s not unusual for builders to examine the community’s availability earlier than making a community request.
The reasoning behind such a examine is that we will 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 sweet UX. On this weblog submit I’d prefer to discover a few of the professionals and cons {that a} person would possibly run into once you implement a community connectivity examine 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 could be 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 practice enters an enormous tunnel.
When you’re stopping a person from initiating a community name once they momentarily don’t have a connection, that may appear extraordinarily bizarre to them. By the point your alert reveals as much as inform them there’s no connection, they may 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.
On account of altering situations, it’s usually really useful 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 to 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 only strive the community name. If the decision fails as a result of a scarcity of web connection, URLSession will let you know about it, and you may inform the person accordingly.
Talking of URLSession… there are a number of methods wherein URLSession will assist us deal with offline utilization of our app.
You might need a cached response
In case your app is used ceaselessly, and it shows comparatively static information, it’s probably that your server will embrace cache headers the place applicable. It will enable URLSession to domestically cache responses for sure requests which implies that you don’t must go to the server for these particular requests.
Which means that, when configured accurately, URLSession can serve sure requests with out an web connection.
After all, that implies that the person should 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 robotically with out even letting you, the developer, know.
Your person could be offline and many of the app nonetheless works high-quality with none work out of your finish.
It will 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 purpose 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 can 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; computerized retries.
URLSession can retry community calls robotically 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 electronic mail) the place it’s fully high-quality if URLSession can’t make the request now and as a substitute makes the request as quickly because the person is again on-line.
To allow this conduct it’s essential 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. Every time I make a request by means of this session whereas offline, the request won’t fail instantly. As a substitute, it stays pending till a community connection is established.
By default, the wait time for connectivity is a number of days. You may 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 means 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:) technique shall be known as every time a activity is unable to make a request instantly.
Notice that ready for connectivity gained’t retry the request if the connection drops in the midst of a knowledge switch. This selection solely applies to ready for a connection to begin the request.
In abstract
Dealing with offline eventualities needs to be a major concern for cellular builders. A person’s connection standing can change shortly, and ceaselessly. Some builders will “preflight” their requests and examine whether or not a connection is on the market earlier than trying to make a request in an effort to save a person’s time and assets.
The foremost 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 shall be there for your entire length of the request.
The really useful method is to only 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 offer information (if doable) when the person is offline, and it additionally has the built-in means to take a request, look ahead to a connection to be accessible, after which begin the request robotically.
The system does a reasonably good job of serving to us help and deal with offline eventualities in our apps, which implies that checking for connections with utilities like NWPathMonitor often finally ends up doing extra hurt than good.
