CODEWITHSUNDEEP
ios
Scrungepipes
Scrungepipes

Reputation: 37581

What's the point of checking reachability before making an internet connection?

Several weeks ago reading through the Apple guidelines it says apps should check for the reachability status before attempting to make a connection, and I've read of apps being rejected from the app store for not doing this.

However the reachability APIs can take up to 30 seconds (according to the Apple documentation, and also I've seen this myself happening sometimes) to determine if reachability is available or not. In this situation the API returns not reachable.

Therefore you can have the situation where you do actually have reachability but the APIs say you don't and you won't find out you do for 30 seconds or so.

Having to wait 30 seconds is unacceptably long - especially if the connection has been initiated by the user. Consider this scenario:

By following Apple's guidelines to first check reachability there is a real chance that an absolutely terrible user experience has resulted and the app didn't contact the server when it could have done.

This seems ridiculous, surely I am missing something?

How can you follow Apple's guidelines while still give a responsive app?

I've experiences these delays in the Reacability API and want to ditch it - because I've seen occasions when it says there isn't reachability but if you try there is, therefore I want my app to try the connection anyway regardless of what the API says. But if I do this then there is a chance the app could be rejected?

Is there a solution to this dilemma?

Upvotes: 9

Views: 2540

Answers (2)

deleted_user
deleted_user

Reputation: 3805

I hesitate to answer this because it becomes a flame war. Answer - reachability doesnt work. The fact that it takes however long on a background thread simply doesnt matter.

The bigger problem with it isnt that it says you dont have reachability when you do, its that it says you do when in fact you dont. Which is the point.

Apple is not rejecting apps that dont use reachability. They are rejecting apps which cannot handle a network switchover from 3G to wifi and back and apps which cant handle losing connectivity properly.

Apps which do not properly ping a reliable backend taking into consideration timeouts and retries regardless of reachability and notify the user when connectivity has been lost will be rejected.

Apps which lock up when the plug is pulled on the network will be rejected.

Although apple has tried to be helpful and clear, the code they provide is not the code they use themselves, and its not sufficient.

You are left as an app developer to make it work for the rejection scenarios above.

Thats it. So forget reachability and simplePing from Apple.

Run your app, kill the network when a request is happening. Does it hang? Fail. Pull the network when a request is NOT happening (but one might soon), do you notify the user?

Thats the whole of app rejection due to network issues.

Dont complain about stuff that has never worked. Although I would like this to be Apples problem, its ours, and I worked too long on my code for this to give it away on StackOverflow.

Ask yourself this, am I pinging a reliable backend?

Am I doing it in a thread?

Am I timing that thread for timeouts?

Am I retrying before overreacting?

Its easy, but then again, its not.

Upvotes: 6

Till
Till

Reputation: 27597

I think you are taking apple a bit too much by their word...

What the HIG actually try to express is that an App should expect to have no connection even if it needs a connection.

So the user should be gracefully told that the connection needs to be active.

What we usually do is that we simply try to reach the service connected to the app and if that fails we tell the user to enable a connection.

Using the Reachability API is not mandatory.

Upvotes: 5

Related Questions