Quite a lot of trendy apps have a networking part 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 aspect processing. When implementing networking, it’s not unusual for builders to verify the community’s availability earlier than making a community request.
The reasoning behind such a verify is that we are able to inform the consumer that their request will fail earlier than we even try and 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 prefer to discover among the professionals and cons {that a} consumer would possibly run into whenever you implement a community connectivity verify with, for instance, NWPathMonitor.
A consumer’s connection can change at any time
Nothing is as vulnerable to vary as a consumer’s community connection. One second they may 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 change to a a lot slower connection when their practice enters an enormous tunnel.
When you’re stopping a consumer 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 as a result of consumer not being linked to the web.
Attributable to altering situations, it’s usually really useful that apps try a community name, whatever the consumer’s connection standing. In any case, the standing can change at any time. So when 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 a lot better consumer expertise is to simply strive the community name. If the decision fails attributable to a scarcity of web connection, URLSession will let you know about it, and you’ll inform the consumer 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 often, and it shows comparatively static information, it’s doubtless that your server will embody cache headers the place applicable. It will enable URLSession to regionally cache responses for sure requests which implies that you don’t must go to the server for these particular requests.
Which means, when configured appropriately, URLSession can serve sure requests with out an web connection.
After all, that implies that the consumer will need to have visited a particular URL earlier than, and the server should embody the suitable cache headers in its response however when that’s all arrange appropriately, URLSession will serve cached responses routinely with out even letting you, the developer, know.
Your consumer may be offline and a lot of the app nonetheless works nice with none work out of your finish.
It will solely work for requests the place the consumer fetches information from the server so actions like submitting a remark or making a purchase order in your app received’t work, however that’s no motive 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 is going to inform you about it.
For conditions the place your consumer tries to provoke a request when there’s no energetic connection (but) URLSession has one other trick up its sleeve; automated retries.
URLSession can retry community calls routinely upon reconnecting
Typically your consumer will provoke actions that can stay related for a short time. Or, in different phrases, the consumer will do one thing (like sending an e mail) the place it’s utterly nice if URLSession can’t make the request now and as a substitute makes the request as quickly because the consumer is again on-line.
To allow this conduct you will 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 and make a community name when there’s no community out there. Every 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 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 possibly can implement a URLSessionTaskDelegate. The delegate’s urlSession(_:taskIsWaitingForConnectivity:) methodology will likely be known as every time a process is unable to make a request instantly.
Observe that ready for connectivity received’t retry the request if the connection drops in the course of an information switch. This selection solely applies to ready for a connection to begin the request.
In abstract
Dealing with offline situations needs to be a major concern for cell builders. A consumer’s connection standing can change rapidly, and often. Some builders will “preflight” their requests and verify whether or not a connection is obtainable earlier than making an attempt to make a request with a purpose to save a consumer’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 really begins, and it doesn’t imply the connection will likely be there for the whole length of the request.
The really useful method is to simply go forward and make the request and to deal with offline situations 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 attainable) when the consumer is offline, and it additionally has the built-in capability to take a request, watch for a connection to be out there, after which begin the request routinely.
The system does a reasonably good job of serving to us help and deal with offline situations in our apps, which implies that checking for connections with utilities like NWPathMonitor normally finally ends up doing extra hurt than good.
