Quite a lot of trendy apps have a networking element to them. This might be as a result of your app depends on a server fully for all knowledge, 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 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 put up I’d prefer to discover a number of the execs and cons {that a} person may run into if you implement a community connectivity verify with, for instance, NWPathMonitor.
A person’s connection can change at any time
Nothing is as vulnerable to alter as a person’s community connection. One second they may be on WiFi, the following 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.
In the event you’re stopping a person from initiating a community name after 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 as a result of person not being linked to the web.
On account of altering circumstances, it’s typically 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 may 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 attempt the community name. If the decision fails on account of an absence of web connection, URLSession will let you know 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 may need a cached response
In case your app is used incessantly, and it shows comparatively static knowledge, it’s possible that your server will embody cache headers the place acceptable. It will permit URLSession to regionally cache responses for sure requests which implies that you don’t need to go to the server for these particular requests.
Which means, when configured appropriately, URLSession can serve sure requests with out an web connection.
In fact, that implies that the person should have visited a selected 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 robotically with out even letting you, the developer, know.
Your person may be offline and a lot of the app nonetheless works superb with none work out of your finish.
It will solely work for requests the place the person fetches knowledge from the server so actions like submitting a remark or making a purchase order in your app gained’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 would 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 robotically upon reconnecting
Typically your person will provoke actions that may stay related for a short time. Or, in different phrases, the person will do one thing (like sending an electronic mail) the place it’s utterly superb 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 habits you could 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 (knowledge, response) = attempt await session.knowledge(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 obtainable. 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 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 method 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 every time a process is unable to make a request instantly.
Observe that ready for connectivity gained’t retry the request if the connection drops in the midst of an information switch. This selection solely applies to ready for a connection to begin the request.
In abstract
Dealing with offline situations ought to be a main concern for cellular builders. A person’s connection standing can change shortly, and incessantly. Some builders will “preflight” their requests and verify whether or not a connection is accessible earlier than making an attempt to make a request as a way to save a person’s time and sources.
The main 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 can be there for the whole length of the request.
The really helpful strategy is to only 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 offer knowledge (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 obtainable, after which begin the request robotically.
The system does a reasonably good job of serving to us assist and deal with offline situations in our apps, which implies that checking for connections with utilities like NWPathMonitor often finally ends up doing extra hurt than good.
