Our lovely app that downloads mp3s from our server into a local file on the phone then plays from that file was rejected for using too much bandwidth.
I understand the rejection (we are downloading rather than streaming) and don't quibble with their decision... our first priority was quality of user experience.
I am just wondering... what do I do now?
There are no hard and fast rules... Apple just says, "Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth".
Anyone have data on what Apple considers reasonable data transfer rates?
Should I fill up the buffer file in short spurts? Should stream the file at a constant rate (and how would I limit the transfer rate from within the app?)
Any and all suggestions are welcome.
Thanks
I have talked with Apple Developer support, and just FYI. You are only allowed to stream 1 MB per minute over the Cellular network. Support suggest that you test your app in the following way:
"The basic measurement methodology is to turn off all background updating (particularly Mail's automatic mail downloads and Calendar updates), reset the transfer statistics in "Settings:General:Usage:", and then launch your application. Let it run for a fixed amount of time (five minutes is reasonable), and then exit your application. Once you've finished the test, the numbers listed under "Cellular Network Data" in "Settings:General:Usage:" are what you should focus on reducing.
Using what I just described, I'd suggest 4.8 MB every 5 minutes as the guideline you use to ensure your application stays within our bandwidth requirements."
Hope that helps at least a little.
Have you considered HTTP Live Streaming? It's built into OS 3.0.
Basically, you split your media into small (say, 10 second) snippets and put it on a standard web-server. Then you create little text 'meta-descriptor' files in EXTM3U format that point out where the bits are. The interesting thing is that you can create multiple versions of each snippet at different bit-rates. So if your bandwidth is good, the iPhone player dynamically chooses the higher bit-rates but when it's low it automatically switches to the lower bit-rate version of the snippet. It does this on-the-fly to adapt to changing conditions.
So if you split your MP3 into multiple 10-second bits at say, 3 different bit-rates then when the user is connected through WiFi they get the high-quality stuff but if they're on 3G or EDGE they get progressively lower-quality (and smaller sized) content.
If this violates your downloadable media concept, then perhaps you can use the same trick and keep multiple size files for each connection type. Then if you're on WiFi (or get a fast turnaround on a heartbeat ping to the server) download the big file vs. medium or small size ones.
Here's a decent step-by-step on segmenting content. They focus on video but it should work with audio content as well.
I would suggest throttling the bandwidth on the network/http request when connected to cellular, and having no throttle on wifi.
A combo of using Reachability to detect the network status, and implementing your http request using CFNetwork with a sleep until the next second whenever you have already downloaded as much as allowed per second should get you there.
You should check out this project, either to use, or just to see an example of how to code this well:
http://allseeing-i.com/ASIHTTPRequest
The ASIHTTPRequest class implements this, using either the old or 2.0 version of Reachability, and also provides a class level throttle, so even if you have multiple concurrent downloads and uploads, so long as all of them go through ASIHTTPRequest, they will be properly taken together and throttled properly.
A bit more on how to use this here:
http://allseeing-i.com/ASIHTTPRequest/How-to-use#bandwidth_throttling
Lots of good stuff in this (and no, I am not the author of any of it).
On a more serious note, what is it trying to do? There are many markets for iPhone outside of the US which don't have good download rates for phones, nor are the download cap sizes good, so having an app do lots of downloading isn't a good thing.
Could you possibly drop the data rate on your mp3 or some such? Make it optional to do the downloading with a warning that it will use your download?
YOu could not download the mp3 unless you are on wireless, and inform them of that. If you the mp3 are too important, then just tell them it only works on wireless, or include a few mp3 on the device. But 30min of mp3 is ridiculous, that is about what, 30meg.... think about it, 30 meg is just too much.
Related
What is the best and most efficient way to benchmark an iOS application? We are mainly looking to get response times for the application to communicate with our API and complete the processing of the returned data.
If you're looking for API response times, you can simply add the two lines of code that measure the times within your app (log at request start, log at request end.)
You can also look into using Apple's Instruments toolset to measure device CPU performance and leaks.
For the quickset-and-dirtiest method of measuring your performance, just NSLog at the start of the request, end of the request/start of processing, and end of processing. That will give you an idea of whether your device or the server are causing a hold-up (something I assume you're looking for). Xcode will timestamp the outputs and you can analyze them after a few trials.
Also, if you run your app in the simulator, it will not give a good representation of phone speed, as it just runs at your computer's speed, but it will give you the option of using the new Network Link Conditioner in Lion to simulate slow and sketchy network connections, so you can see how the network performance would feel out in the field - just make sure to bear in mind you won't have the comfort of the extra processing power.
Flurry provides decent, free analytics and support timed events. Take a look: http://www.flurry.com/product/analytics/index.html
This is good if you want to collect data from other folks running your app.
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 learning to use Manifest files and had this question. What if some website created a manifest file that will make me cache files for, say, 3MB. 3MB is a lot for my IPhone when I run on 3G. So some vicious website can create such manifest file and make me use up all my data allowance?
Another question is that, as a responsible developer, is there anyway to detect if a user is using 3G or not so I can serve a smaller manifest file in the former case?
Thank you
Your question is tagged 'iPhone' so I am going to give an iOS-specific answer.
The offline storage, which holds the files linked to in your manifest, seems to be limited to 5MB. Evidence for this is all circumstantial, as the limit is not mentioned in Apple docs. However, some Apple engineers have conceded that there is a limit. The newest versions of Mobile Safari, in some circumstances, offer to allow the user to expand the storage, but you, as a developer, cannot force them to do so.
5MB is not really that much, and many users will certainly notice that something is going on, and if they don't want it to happen, simply close the tab. I understand that not every country has the same limits, but most users in the US are limited to 2GB/month. At this rate, an unsuspecting user would have to accidentally re-download your manifest, and the files it lists 100 times to use up just 25% of their bandwidth allotment. It's a fairly low limit, and the possibility of maliciously using up someone's data allotment is fairly remote.
As far as how to tell if a user is on 3G or WiFi, check out the Reachability example in the Apple Developer Center. It does exactly that. There is no way to do it in a web app (as opposed to a native app) that I am aware of.
Is there a size limit for HTML5 Manifest? No.
No, iOS does not implement W3C network information API as oppose to Andorid Webkit.
I'm not sure how you're getting this manifest file, but if you're using NSURLConnection, it's simply a matter of keeping a running total of how much data you've downloaded (best place would be connection:didReceiveData:) and cancelling the connection if it gets above 3MB. Remember to zero that number each connection though.
As for finding the device, the specifics seem trickier than they should be, but I've found a pretty simple example of how to do it (source code n' all): Determine If iPod is First or Second Generation
I know nothing about iPhone development, but I am drafting a proposal for other people to do the work of creating an App that interfaces with existing systems and data.
I need to know if the 20MB cellular data download limit present on all apple produced apps is enforced by the SDK for 3rd party apps - i.e. If i develop an app that tried to download a larger file will it fail?
Context:
The data file we use is approximately 50MB and many of our customers work on the road and have no access to wifi. If the limit is enforced I need to be enable HTTP Range header support on our server and add this to the requirements for the App so that the file can be downloaded in 20MB chunks.
Thanks
No. The 20MB limit is one imposed by the App Store itself. The only restrictions seen in third-party apps are ones that the cellular provider wishes to enforce (which typically just means bandwidth caps or overage fees if you go over a download cap). That said, it may be useful to support HTTP Range anyway, in case the download is interrupted and you wish to resume it.
It is enforced; I did not understand your other points.
The limit exists for downloading both apps and media files (videos, podcasts, etc.), so I'd imagine it's limited for downloads within each app as well.
Trying to determine what's "most" responsible for latency - the round trip my video makes from my encoder, to my server, and back down to the player in my browser.
I'm at about 12 seconds right now with a player I like. Is it buffering in my player? Buffering on the way out by FMLE?
The reason I ask is I feel I've eliminated other culprits with my little test scenario outlined below. And also, all else equal, swapping other players in produces the greatest variance in the latency. One takes it down to 4 seconds. Can't get any lower than that though.
Eliminating other culprits:
-Bad network? Nope, running it all locally.
-The codec?, Nope, setting FMLE to VP6 or H.264 produces same latency.
-Pushing too much data out of FMLE? Nope, 50kbs or 1000kbs produces 12 seconds
-Framerate settings to intense? Nope, 5-29.97 fps changes effects motion quality but delay stays around 12 seconds.
I'm developing a small FMS based web presentation package so the latency will have to be down to a second at most. I've seen a similar package with almost no latency. Here's my test set up:
-Camera connected to Windows XP machine
-Flash Media Live Encoder 3.0.1
-FLash Media Server 3.51
-Video Player - Sample dynamic streaming player in Adobe Flash Media Server productivity tools (kind of like a reference implementation for Adobe's ActionScript 3.0 Dynamic Streaming Class)
If I bounce my video off a server about 30 miles from me the result is nearly identical.
I ran a test with a CDN and a player they provided and the best I could do was 4 seconds.
Does anybody have a really fast player I can test?
To make low latency web stream, do the following:
Setup your encoder normally and point it to the media server
Check media server edge configuration for low latency configuration, Wowza has low latency app built-in
In your player, make sure your buffer is 2 second or larger.
ps. With player having buffer less than 2 second it will not work properly for most people, especially over wifi or long range links.
ps2. If your encoder is on the same LAN as Encoder, you can use low latency app for origin application as well.
ps3. You will never go below 4 seconds and reliable stream at the same time, but if you will do extreme tuning on your LAN part (no buffering for encoder at all - you can do it), by just using buffering on edge you can archive 2 seconds - I have such player but it's not public :(
I would like to share my experience since recently I have been researching into this world of CDN and live video streaming.
My best result has been 2 seconds latency.
I have tried a few providers and I would like to know if anyone knows of any other provider that gets to that low latency.
I achieved those 2 seconds with The Original Livestream, do not confuse with The New Livestream (16 seconds latency).
Both, The Original Livestream and The New Livestream, are part of the same group, Livestream, but it seems they target a different market segment.
They also told me that although they area still supporting The Original Livestrean, they are not longer developing it.
It is not very reassuring when they tell you that they not longer develop the platform, this is the only reason for which we have decided not to get on board with them. You will also have a hard time when you try to get support from them if you want to get access to their RESTfull endpoint for the Guide API.
Still, 2 seconds latency.
I am based in London by the way.
Please let me know if you have some other ultra low latency CDN.
Ah, the url for the original livestream is not easy to find, here it is... https://secure.livestream.com/
Take a look at NetStream.setBufferTime() and ns.bufferTime in the FMS documentation. Also like Robert mentioned the player has its buffer too.