Many reachability test codes seem to incorporate "notify" concept so that when network gets back on, user can get notified.
Do I need to implement the "notification" part? Is it acceptable to alert user whenever he tries something that needs network connection and it is not available? (without notification when connection gets back)
I see example codes deals with pure network availability(if the device is connected to wifi, 3g, and so on) and with reachability to specific ip. My app needs to connect to specific ip address when appropriate. In this scenario, just alerting if that ip is not reachable in appropriate times are all that's required or do I need to handle something more?(such as putting different messages for alerting user to turn on network and for alerting user that my ip is not reachable)
Thank you
1.
I'd recommend taking a look at Andrew Donoho's Reachability class that is an extension of the sample released by Apple:
http://blog.ddg.com/?p=24
That'll abstract away the need to worry about handling the notifications and allow you to focus on simply testing the reachability of your IP or if a certain network type is active.
2.
In terms to actual notification to the user, I'd say that depends on your application. For instance on the vast majority of the screens on one of my Apps the UIView attempts to do an async download of data from a RESTful service when that view loads. I don't do any reachability tests beforehand, I simply attempt to make the call and if the request fails, I notify the user after the fact. Unless you have a specific case of needing to know an IP is reachable, I'd think in the general case handling any errors on connections attempts should be sufficient. I'm sure there are are plenty of edge cases though that you might want to test reachability first.
On the other hand I do use the reachability on a given screen that I recommend a WiFi connection. Since that screen performs a fairly data intensive sync, I warn the user if they are on 3G that the sync make take quite a bit longer vs. WiFi simply performs the sync.
AFAIK, there is no requirement that you pop up a notification when the network becomes available, or in fact that you actually pop up a notification when the network is not available. You could instead enable/disable network-related buttons (as long as the user can know why the buttons are disabled), display an unobtrusive on-screen indicator, or whatever.
The important part is that you do not display a blank screen or a cryptic error message when the network is not available, or otherwise leave the user wondering why things aren't working.
I don't know of any requirement that you differentiate between "networking off" and "networking on but IP address unreachable".
Related
OK, so I specified a UIRequiresPersistentWiFi key of my App's plist to YES so the iOS won't stop fetching the data when my app is in the background.
However, when the user uses cellular connection (not wifi) and my app is in the background, the download of the data is stopped after several minutes.
I double checked the docs and it seems there is no equivalent of UIRequiresPersistentWiFi for cellular network that I could set.
Is there any way I can make the connections over cellular network survive while the app is in the background? Any hints?
Cheers!
Updates:
I am making an Internet radio app. Stream is combined with mp3s which I request one after another (can't request them in advance, can't change server side). It works when my app is in the background and uses wifi. However, when using cellular connection the network requests are not performed after some time spent in the background. There is no place for changing the strategy. The app is in the AppStore and it had worked before. I guess they changed something in the new version of the system.
What is more I do not need throttling. My radio app has been already approved and is in the AppStore. The stream is sent with 128kb/s (that is the maximum) so that is not a problem. It looks like system silences my network requests (when on cellular network) after some time in the background. However, this only happens when I try to start the connection in the background.
Description:
App is in the background playing a mp3 streamed over cellular
network.
Mp3 ends
I request the URL to another mp3
The request is not performed*.
*works when using WiFi.
I'm fairly certain there isn't something like this for Cell networks. Here is my reasoning:
Cell service costs money. A LOT of money. Per minute. Wifi service does not cost money, in comparison.
AT&T does not have very much bandwidth, and charges users extra for extra bandwidth usage.
Apple is a company that wants to make the user experience as clean and nice as possible.
When costs are exorbitant through no fault of their own, users are angry and their experience is not nice.
If Apple lets you have a constant connection to the web outside of wifi range, the user's cost of service would skyrocket and they wouldn't know why. And if Apple gives programmers this ability, somebody would abuse it. So, I'm sure that Apple won't allow you to do that.
Why do you need a constant internet connection when your app is in the background anyway (unless, I guess, you're making an internet radio app)? Keep in mind that, when in the background, your app can be terminated without warning at any time. You may want to rethink your strategy if you can't find a way to do this. :/
I think there is no equivalent of UIRequiresPersistentWiFi, there reasons probably include the ones pointed out by Tusting2121.
But please note that UIRequiresPersistentWiFi is connected with energy saving. The wifi module consumes energy, so normally it is shut down after some time to save some energy unless UIRequiresPersistentWiFi is set.
Such enrgy saving, I believe, is not a case in cellular case.
And the fact that your connection disappears after certain minutes in cellular mode may be caused by something completely different that the copy of wifi energy saving mechanism you claim. See for example this article which suggests that you are obliged to throttle your 3G data flow.
Add audio to your UIBackgroundModes entry in Info.plist.
According to the Apple Docs: In your callbacks, though, you should do only the work necessary to provide data for playback. For example, a streaming audio app would need to download the music stream data from its server and push the current audio samples out for playback. You should not perform any extraneous tasks that are unrelated to playback.
You may also get some value out of the voip entry - you can setKeepAliveTimeout:handler: to have your handler called on a periodic basis to populate your data stream.
I have a app from where i hit different REST urls. one of the service is login service.
Now, do i have to use the apple rechability test everytime i want to make a connection?
I use ASIHttpRequest
No, ASIHTTPRequest will return a timeout error / a connection failure error if it can't reach the host. You can use those errors to show something to the user to tell them their login has failed.
The connectivity status of your mobile device can change very often and unforeseeably, so checking it often is advisable.
Say, for example, that you check at app startup, and find that not network is available. You go to offline mode, but then in a few minutes you could get in a WI-FI area or your 3G signal might be stronger. If you don't check it again, you lose the possibility of going to online mode.
Indeed, checking for network availability is pretty fast compared to how long a network request lasts (say: sending a login request and waiting for the response), so you can safely do the check whenever you need it according to your policy, be it at each request, every 5 minutes, or whatever.
EDIT:
about your concern as to the approval process: you should ensure that your app has a reasonable behavior when no connection it available. Simply showing an alert to the user (and not crashing) is enough for Apple, but you could also resort to disabling all your network related buttons, or whatever fits your app. The idea is that your app should not behave crazily when no connection is available.
If you want more advanced behavior, you can check reachability with each request.
You can also use the Reachability notification service (ASIHTTP-bundled Reachability includes that feature). You can find an how-to here. But in my opinion is a bit easier to just do the check when you need it. YMMV
From what I remember the reachability demo code is effectively a listener so can update a variable as the device's reachability state changes. You then need to check this variable before making a request.
Would be surprised ASIHTTP doesn't do this kind of thing already.
We are developing an enterprise application .The phones are connected to a Wifi router. The objective is to trigger an alarm if the phone moves out of the secure area .. (outside the building)
What is the best way to check if the iPhone is always inside the building .
some of the options we tried are
1.using Wifi(continous ping to wifi network),if not trigger an alarm .
2.if coordinates change (using GPS)
Are there any other means to achieve this .
You can use Location Services in iOS 4 (with the background location feature) to determine when the phone has moved to a different location.
#indragie's idea of using Location Services is a good one. If you can be sure that the WIFI SID isn't going to change, you could probe to see which access point the iPhone is currently associated to. If you are going to ping, then a better approach is to make the system service agnostic, and simply issue an HTTP query on a regular basis to your enterprise server. The server can then have a policy language on it declaring acceptable access points (from a variety of metrics). This might be set up to allow people to take their iPhones home.
Your best bet is GPS as the phone will not be able to find its location if you rely on WiFi and the device is not connected to a WiFi network.
Check out Apple's documentation for Location Awareness capabilities here http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html
You will be able to track "significant" or standard location changes in the background, details can be found here http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH5
[edit to include]
This might be of interest to you too - http://longweekendmobile.com/2010/07/22/iphone-background-gps-accurate-to-500-meters-not-enough-for-foot-traffic/
It depends on what you want to do. Just to let the iPhone user know that he/she is moving away, using Location Services is good enough.
However, if you want to have a server that makes sure all the devices are within range, then it's more complex because your application may get suspended without a notice from a background state; in other words, you may not be able to catch the moment when your application terminates and take appropriate actions. Therefore you are going to need a heartbeat system like pinging to the server in this case.
Is it possible to have an iPhone app which carries on listening for data on a port when it is sent to background by the user and if any data comes the app can show a local notification and alert the user? I know the multitasking is deliberately limited but wof it allow for that?
It can but with major caveats:
First, the system will unregister any Bonjour names you might have established.
Second, if you're bound to the WWAN, it will go down even with you listening on it (this is true even in the foreground).
Third, if your app is not doing anything else in the background (i.e., isn't registered to provide background music, location events or telephony), you must still shutdown within the time limit for background task completion or be terminated.
So, while you could bind and listen on a socket in the background, for almost all practical purposes, it's not worth doing and you should rethink your design.
This is exactly what push notifications are for. Your application doesn't listen to your server, your server tells Apple's about any notifications, and Apple's server delivers them to the user and your application if the user wants them.
The app i'm developing for the app store infrequently needs network connectivity. I've already implemented a way to handle/notify the user when there is no network connection, but that only happens when they've initiated the request (click a button to make a web service call).
My question is, Does apple require a continuous check for network connectivity, i.e. their reachability example, or will the method I have implemented (checking for network connectivity only when certain actions are triggered) be acceptable for app store submission?
Thanks in advance.
Checking for connectivity only when it's needed is sufficient. In fact, Apple discourages using Reachability as a "pre-flight" check. They say to just handle failure gracefully, and then use Reachability if necessary to watch for connectivity to come back.
It is acceptable for app store submission. In fact, I'm sure AT&T and Apple would prefer it.