What is the advantage of using Reachability?

Question

What is the advantage of the using Reachability over the code below? I feel that Reachability has a huge amount of code, but if it's better in any way, then I'd use that instead.

NSString *connectionString = [[NSString alloc] initWithContentsOfURL:[NSURL URLWithString:@"http://www.google.com"]];  if ([connectionString length] == 0) {      //No connection  } 

Now granted, if Google ever went down then this wouldn't work. But there's literally no chance of that happening. What do you think? Thanks!

Answer 1

This is actually quite a good question - so good that I actually use it in iOS developer interviews when my company is recruiting:

Why is Apple's reachability example hundreds of lines long, when you can just use a single line to check if a URL is responsive?

Firstly, network reachability is actually very, very complicated. It's much more than simply testing for a URL. Think about the following examples:

• The user is on 3G, but has used up their data allowance, so every request redirects to the carrier's site.

• The user is connected to a public WiFi network that requires authentication / login, so the request redirects to a log in page

The last example is incredibly common - it happens all the time. But if you used initWithContentsOfURL your app would imagine you had connectivity, when in fact you didn't: you would simply have been returned the contents of the page the network had redirected you to.

This is one reason why Apple's code is more complex than you might at first think it needs to be. You shouldn't just be asking "can I reach this URL", but "is the data being returned from this URL what I expect it to be".

But that's really just the tip of the iceberg. Reachability does a lot more besides that - for example, I might have an app that needs to download a lot of information, say 50MB worth. It would be a bad idea to simply download 50MB of data if the user was on a 3G connection without their consent - especially if they are roaming, or on a restricted data plan. So Reachability will also tell you what type of connection the user is on: EDGE, 3G, WiFi, etc (*NB: see the note below, this is probably not the best advice).

The ReadMe.txt inside Reachability will tell you a little more about what the code can and can't do.

Unfortunately, there are all too many people online who don't realise that there are many everyday scenarios where initWithContentsOfURL will return a valid response but the user won't have connectivity. [Blog posts like this][1] get indexed in Google, and people assume it's an acceptable substitute: it's not!

One of the reasons I ask this question when recruiting is it can show a developer is not just thinking inside the box - like you and many other developers, my first reaction when I saw the Reachability sample code was "wow, this seems way too complicated for something that's very simple". But hopefully this answer will have gone some way to convincing you otherwise.

---

Edit: Definitely take note of Steven's comments below. He raises some points that my answer hadn't considered (i.e., MiFi hotspots), and makes a valid case that Reachability isn't necessarily the peak of coding heaven it code be. In many cases developers will modify Reachability with their own improvements and the like.