For a long time, I was checking the network availability via a simple
return (url("http://....") is tValidResponse) method.
Unfortunately, that isn't reliable always.
Because iOS has an advanced cache mechanism
and may respond to a subsequent checkConnection call with a false-positive.
That is, even if there isn't an active connection, the above method may result with
true.
I've tried pulling the current time from a php script and checking it against the system time of the device;
but that didn't go well, either, at a scenario like:
There's connection, so the response should be Apr 17th, 2014 - 06:02:58.
But since iOS looks at the cache first, the response is, say, Apr 17th, 2014 - 05:28:17.
Clearing the cache is possible and I do it on occasion.
But clearing it each time one checks the connection doesn't seem as a good approach and may break things.
Then, I turned my eyes to the built-in method.
It was stated as
experimental in the Livecode User Guide.
But the dictionary doesn't mention about any experimental aspect and User Guide isn't published anymore.
So, I gave it a try and put a simple test stack together:
Here are the gotchas:
* If there is
http:// in the server address, then the result is always
empty which means
no connection.
www.example.com is ok;
example.com is fine, too.
* Despite the definition, putting an IP address won't work.
The result is not empty, engine just ignores the command and doesn't fire up any
reachabilityChanged messages.
* If the connection is too slow, then the result is
empty which means
no connection.
Even if there is a connection and safari can open that particular webpage.
Test scenario:
Bad reception in iPhone {Edge} which shares its connection to an iPod {tethering, portable hotspot}.
The stack on iPod reports
no connection although it's connected and can open webpages.
This isn't a bad thing after all, with a connection that slow,
one wouldn't want to interact with a server and try to get a content update.
I don't.
Bottomline?
Built-in reachability method is reliable
as long as you don't prepend an
http:// to the url
and you don't use an IP address.
Best,
~ Ender