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.
Related
I have an application that requires location tracking and I think it fits squarely within one of the allowable background models. However, I need to post to a network service when there are significant changes of location. I've seen write-ups that state network access is prohibited in background processing, but I didn't read that in Apple's docs.
Does anyone know if it's kosher (wrt Apple policies) to make occasional and very quick network updates in a background process?
Good point, according to the Apple documentation only the following usages are allowed in background and each service should be registered:
audio—The app plays audible content to the user while in the background. (This content includes streaming audio or video content
using AirPlay.)
location—The app keeps users informed of their location, even while it is running in the background.
voip—The app provides the ability for the user to make phone calls using an Internet connection.
newsstand-content—The app is a Newsstand app that downloads and processes magazine or newspaper content in the background.
external-accessory—The app works with a hardware accessory that needs to deliver updates on a regular schedule through the External
Accessory framework.
bluetooth-central—The app works with a Bluetooth accessory that needs to deliver updates on a regular schedule through the
CoreBluetooth framework.
Other than this services, you can create a Finite-Length Task in the Background that actually give you the possibility to end a network process.
This can be important if your app is performing some important task,
such as writing user data to disk or downloading an important file
from a network server.
Regarding your question, it's not really clear if you can or not can do a quick network connection if you've a location service running in background. I would say YES for a short connection, but not totally sure. Since iOS 4.0 this usage was denied and clear in documentation, now that part has been removed.
Yes if you use background for just quick connection. Apple won't allow you to run in the background as you want.
NO If your app does not fall in the Voip, music or GPS category; then you can't run in background.
more here: Update my app when it is in background
You could use ASIHTTPRequest.
ASIHTTPRequest has a property setShouldContinueWhenAppEntersBackground:. default is NO, you may turn on YES so you have background network process.
Apple documentation seems a bit unclear on the strict policy. There are definitely applications in the app store that make sporadic network calls while running in the background as a location-based application. An example is the Geoloqi application.
My app was rejected because one of the features is streaming Podcast audio from a website. Apparently, it may stream over 5MB/5 minutes which is against section 9.3 of the App Store Review Guidelines (https://developer.apple.com/appstore/resources/approval/guidelines.html).
Their suggestion would be to use Reachability to restrict that feature to WiFi. My question is, is there any other way to get around this? Perhaps to only let the user stream 5Mb worth of audio before displaying an alert to switch to WiFi? I don't see anything in Reachability about data usage... is there any other Framework that could keep track of data usage?
ASIHTTPRequest has inbuilt code to throttle bandwidth when the user is on 3G. This uses a modified version of the Reachability sample. The source is available, so take a peek if you want to try doing this yourself. It dodges the 5mb/5min limit by slowing down the download speed to a rate at which that limit won't be hit.
I think Apple's guideline is a reasonable one. It's not only to prevent users running up big data bills, but also to help reduce congestion on data networks.
As for your idea of letting user stream over cellular for 5 minutes, then prompting them to switch to wifi -- I think this would make a for a poor/annoying user experience, as opposed to just prompting them from the start to use wifi. If they use wifi from the start, they will:
1) have less probability of having choppy audio
2) waste less of their cellular data allowance/cost
3) not have a break in service after 5 minutes which might interrupt their flow, at which point they have to fiddle with their phone
I don't think any framework tracks the data usage for you (you get to do that yourself), Reachability is used to find out if you are on WiFi or 3G.
I am developing a voice recording application that communicates with the server real-time, therefore requiring persistent Internet connectivity. I have included UIRequiresPersistentWiFi in my info.plist and have also disabled device going to sleep when the app is active. However, this understandably has a serious effect on the battery life of the device. Users end up having to leave this continuously plugged in. For an app that is touted as meant to replace handheld recorders, this is a serious shortcoming. My app also has many xml threads sent from iPhone to server, so wireless connectivity is of paramount importance.
My questions are:
1. Is it possible to somehow switch on UIRequiresPersistentWifi status only when required during a session. For example, can this be switched on only during transfers or xml updates to server and be switched off at other times?
2. Likewise, can IdleTimer be enabled and disabled programmatically at will during a session. For example, enabling idletimer only when no foreground or background tasks are running on the device.
Any other suggestion to ensure normal battery life? All my users will be on iTouch 4 or iPhone 4.
Any help/suggestions would be greatly appreciated.
Answer to part 2: Yes, you can enable and disable the idle timer depending on what the user or app is doing, and how long it's been. I know of a couple apps that disable the idle timer, but then re-enable it if the user doesn't touch any UI elements for 10 minutes, but then re-disables it if the user starts some long operation again. etc.
Partial answer to part 1: Using the radios (sending wifi data) takes power. A good way to save power is to not send data for as long as possible. Maybe buffer large amounts of data on the device, and try to burst upload it later.
My suggestion would be to not communicate with the server continuously, sorry :(
Is it possible to cache chunks of data into a file on the phone and transmit the chunks to the server periodically in one big burst? Same for the XML. Or does your app really really require it to be broadcast real-time?
And as far as I know, if you have specified UIRequiresPersistentWifi, you're stuck with it :(
Sorry, probably not the answer you want!
Sometimes the iOS device will not connect to the available WiFi automatically, but it will if Safari is launched and try to browse to any site (or go to Settings->Wi-Fi and select the desired network). This is probably for battery savings reasons.
How to trigger this from your app?
The higher level Cocoa Touch network APIs will attempt to turn on the radios if needed. Until then they are kept off as much as possible to conserve battery power (after certain time-outs).
Safari probably uses one of the high level HTTP APIs for browsing.
You can try something like <key>UIRequiredDeviceCapabilities</key><array><string>wifi</string></array> in Info.plist. It actually means "persistent wifi" (i.e. keep Wi-Fi up even when the display is asleep), but it might also trigger a reconnection.
EDIT: Alternatively, <key>UIRequiredDeviceCapabilities</key><dict><key>wifi</key><true/></dict>. There's also <key>UIRequiresPersistentWiFi</key><true/> which does something slightly different.
I'm having trouble keeping wifi from disconnecting after 30 mins in an iphone app that needs to function when locked by the user.
The app normally does not sleep, but if the user so chooses they may lock the display. I'm adding a new feature to the app that sends data out over the network at 1 second intervals. prior to this there has been no network requirement for the app, and it has functioned as desired (music, timer-based processes) while user-locked.
The answer seemed to be here:
Wifi connection doesn't stay alive when asleep, with iOS4
But adding UIRequiresPersistentWifi boolean to info.plist doesn't keep it from timing out the wifi (i'm testing on Touch, iOS4.02) after 30 mins, even while the app is busy sending data out over the connetion. Maybe this only applies if the display sleeps itself, rather than user locks?
Related, I think there is no way to "stir" the display at any interval? User pressing the home button is sufficient to bring back the wifi; unlocking is not necessary.
Also, I've read on the interwebs that it was stated in a WWDC that UIRequiresPersistentWifi applies to keeping alive 3G as well. Can anyone verify?
thanks
Your app may be getting suspended by the OS after a long enough period of user inactivity.
Under iOS 4.x there are certain types of apps that aren't suspended when the display is locked (music player, VOIP, etc.) Apps that register as a VOIP type app might be allowed to keep a persistant network connection over a longer period. However Apple may require that an app actually provide some VOIP functionality in order to register for that type in any app submitted for review.
Is there some activity that you need to perform network activity? From iOS5 onwards, we have noted that even if we send network packets (heartbeat timers), then also iOS 5 blocks it after locking device.
It is to be noted that services which requires VoIP continue to receive calls, and notifications do come when your phone is on sleep mode or locked. This means that WiFi is not totally closed. I dont know how this happens.
As an alternative you can use data carrier of your network provider as an alternative to WiFi in case WiFi has gone down. With UIRequiresPersistentWiFi, you just inform iOS5 that you would require WiFi to run your application, nothing else signifies whether it keeps your screen ON or OFF. For keeping your phone from autolock you can however use disableTimer = YES flag, in lieu of your battery charge.