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.
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.
Is there a system network reachability notification, that sends wifi/3G change notification to application in suspended mode, so it can wake up application?
I couldn't find that topic in Apple developer guide and example code like Reachability only works when application is not suspended.
It is not possible to do this legally. If you do find a way (by say pretending to be a VoIP application, Apple wile most likely not approve your app.
This might help: https://github.com/tonymillion/Reachability
To quote:
This is a drop-in replacement for Apples Reachability class. It is ARC compatible, uses the new GCD methods to notify of network interface changes.
In addition to the standard NSNotification it supports the use of Blocks for when the network becomes reachable and unreachable.
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".
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.
How does Apple do polling of a phone's location remotely? Is there any API that allows an app developer to do the same with the SDK?
My guess is that they are private, undocumented and probably un-callable api's.
I couldn't imagine the huge security implications of having an external party/app be about to poll a phone location without the users consent.
An iOS device already maintains a connection to one of Apple's push servers if push is enabled, and the server has to know the device on the end of the connection (to determine the push notifications to deliver to it). The easiest way to build on this is to have the server say "tell me where you are!" as a push notification.
The device also hits Apple's servers for other reasons (App Store updates, captive login page detection), but it's less likely that the server can identify the device in these cases.
That said, you can do this with the user's consent:
Make your app a background "voip" app (<key>UIBackgroundModes</key><array><string>voip</string></array> I think)
At app launch, check that you can retrieve the current location (I'm not sure what happens if you do this while your app is backgrounded).
Maintain a "voip" connection to your server.
When the server asks the device for its location, ask Core Location for the location again and send it to the server. (I think you also need either "location" in UIBackgroundModes or you need to keep the connection active, possibly in both directions; the former may be easier.)
You won't be able to stop the "location services" icon from appearing in the status bar. The usual multitasking caveats also apply (your app can be killed if the phone runs out of memory; "voip" causes your app to be relaunched sometime later though).
I'm pretty sure if you do the "voip trick" your app will be refused from the store. It is only allowed if your app is actually a VOIP app, not just using it as a technique to circumvent background processing restrictions.