My iPhone app requires internet to function.
Should I checks for connectivity everytime a internet function is executed?
Or should I use my appDelegate to listen for messages from something like the reachability class to determine if the connection was lost and warn the user?
What is better?
Here's what I've done so far in my app delegate:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(reachabilityChanged:) name:kReachabilityChangedNotification object:nil];
reachability = [[Reachability reachabilityWithHostName:[NSString stringWithFormat:@"http://%@/iSql/" ,[[NSUserDefaults standardUserDefaults] stringForKey:@"serviceIPAddress"]]] retain];
[reachability startNotifier];
return YES;
}
- (void)reachabilityChanged:(NSNotification *)note {
NetworkStatus ns = [(Reachability *)[note object] currentReachabilityStatus];
if (ns == NotReachable) {
if (![networkAlert isVisible]) {
if ([self networkAlert] == nil) {
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"\n\nNo Internet Connection" message:@"You require an internet connection to retrieve data from the server." delegate:nil cancelButtonTitle:nil otherButtonTitles:nil];
[self setNetworkAlert:alert];
[alert release];
}
[networkAlert show];
}
} else {
if ([self networkAlert] != nil) {
[networkAlert dismissWithClickedButtonIndex:0 animated:YES];
}
}
}
At least one Apple tech talk presenter recommended not checking Reachability in most cases, just firing off your async network requests, informing the user (via some type of activity indicator) that the app is waiting for a network response, and giving the user an option if in their opinion they've waited long enough, instead of locking up the UI or the app.
The reason is that, on a moving mobile device, the network can and will often go up between the Reachability tests and any actual data requests. Thus the user will be misinformed. The net can also go down after informing the user that there is connectivity, which can even be worse.
Plus Reachability only tells you about the connectivity of the nearest/1st network hop, which may or may not provide connectivity to the rest of the internet or to your destination site. Common example might be all those misconfigured WIFI access points.
Locking up the UI, and not giving the user any option after waiting long enough is likely grounds for rejection, whether or not you've checked Reachability first.
It really depends on your application. You could do both: disable functionality when the internet is not available and inform the user.
I prefer to change the UI when there is no internet connection, and make sure there is connectivity before firing off any methods that require a connection.
I recommend:
1) Always check for internet connectivity prior to making any internet request and handle appropriately.
2) Have a polling mechanism that will check reachability. If unreachable, perhaps warn the user AND disable portions of your program that make internet requests. Maybe call it 'Offline Mode'.
Checking for internet is technically up to you as the developer to decide, but Apple has in the past rejected apps for not notifying the users that the internet connection was not available.
http://mobileorchard.com/avoiding-iphone-app-rejection-from-apple/ (#6)
