In OS3.1.3, I can create 6 UIWebView in a single view to watch 6 MJPEG stream simultaneously.
For the same application, it can run in iOS4 without any code modification.
But it can only show 4 liveview feed at the same time. And I cannot send any request afterward.
Is this a limitation for iOS4 for multitasking?
Or I use some deprecated functions, and I need to replace them?
Any suggestion is helpful, and thanks in advance.
Best Regards,
Jamie Chen
My first thought is to question memory usage. I am guessing you are trying this on a 3G S, and if true, this means you have 256 MB memory. The same is true for the iPad. The iPhone 4 has 512 MB.
Have you checked to see how much memory each UIWebView/Video Stream is chewing up?
I found the reason for the problem. The connection counts is limited by Safari.
This URL can test the number of parallel connection counts.
http://www.spasche.net/files/parallel_connections/
And the connection count of Safari is 4 in iPhone4.
Now, I am looking for solution to increase the connection count.
But I am wondering if I can find out...
Are you connecting to the same host? This could be a server or firewall issue where it only allows 4 concurrent connections from one client to one host.
Related
My application allows the user to download relatively large files (~120 MB) from my own dedicated server. I'm using the ASIHTTPRequest library for downloading.
It may sound weird, but everything worked fine until yesterday. I've tried downloading files countless times both from my app (on an iPad) and a Mac, and while on the Mac the download succeeds, on the iPad it randomly times out. Sometimes it goes until 100%, sometimes it reaches 30%-40% or something and then ASIHTTPRequest's downloadFailed: selector gets called. If I print out the error's localizedDescription, I get "The request timed out".
What could this mean? Could it be a problem of my app? Or a problem with my server, or my connection? I realize this could depend on several factors, so please ask me any information you need if necessary. Thanks.
I had weird network situations like timeouts on my ipad when using wifi that started after the upgrade to 4.2, but were intermittent.
Going to Settings -> General -> Reset Network settings and then reentering the wifi settings solved it for me.
(Also check that someone hasn't recently setup a new nearby wifi access point on the same channel as your network!)
Does your server have limit about the number of connections ? I encountered a problem because the number of connections are too much, then the server declines those connections. Then, they are time out.
Do you use WiFi or 3G connection? Non-WiFi connection allows to download files with maximum size of 20Mb only.
I need to develop an enterprise app that monitors the network traffic. Basically it detects if the user is in wi-fi or cellular data and save the amount of bytes was sent and received in a period of time.
I saw an App at the AppStore that do exactly this job.
Detecting wi-fi or cellular data is quite simple using the Reachability Sample provided by Apple.
My problem is to keep monitoring the bytes sent and received while the app is in background.
As it is an enterprise App, I used UIBackgroundModes "voip" to avoid the app to be terminated.
I also installed the setKeepAliveTimeout method and I'm able to see the logs each 10 minutes, BUT only for 10 seconds after the method runs. I mean, setKeepAliveTimeout brings my App to run a Timer for 10 seconds each 1o minutes.
I'm thinking wether or not a task in background is the best solution for my problem.
I'll appreciate any comments.
EDIT: Ok guys. Thats the perfect way to do it.
First of all you must read this:
http://www.christian-fries.de/blog/files/tag-ios.html
I tried this and it works really fine.
All we need to do is to create a second thread detached from the main one. This way we have a continuos threading running forever. You must see the GCD docs at Apple's website also.
Second thing you should consider for an enterprise App is to set it up as a voip App, this way iOS will put your App running even after a reboot. It's a special behavior iOS has to keep voip Apps running.
Thats it guys.
I hope it can help you.
We dont have access to this data. There is no way to measure traffic.
The app you saw made an estimation (eg. 1mb/min) and after applicationWillEnterForeground. then you calc time x estimated-traffic and there we go.
Unfortunately there is no way to measure,
so I did a traffic-reset in settings and then i streamed exactly 1 min music. after a few repetitions I had my results. The problem is, that this works only fine with static traffic-processes like audio or video.
hope could help
endo
EDIT: look answer below!
If I try to download an app that is lets say 100 MB it will not allow me to do it on my phone. Or if I am not connected to a WiFi. Does anyone know where they cut that off? Like at 30 MB or something you have to be connect to WiFi?
Thanks
I did a little looking and it still says 10MB online as far as I can tell, but it seems they may have quietly upped it.
Here they show people being given a 20Mb limit. It seems they may have upped it. I will keep looking for official documents.
After continuing to look I have found many more sources backing 20MB. just take a look at google for it. My rep only allows me to post one link.
20 MB is the current limit.
According to Macworld, it was raised to 20MB from 10MB back in February 2010:
http://www.macworld.com/article/146512/2010/02/appstore_limit.html
I can't seem to find this anywhere, but I'm sure there must be an answer...
How many simultaneous HTTP connections can an iphone app service? In other words, if I build and run a bunch of NSURLConnections asynchronously, how many can be in flight before it starts queuing them?
Also, is there a method to check how many threads are available and/or in use programmatically?
I'm trying to write an intelligent pre-fetching engine, and these limits (if any) would be useful information.
The iPhone doesn't start queuing NSURConnections. That's totally your responsibility. The iPhone will start all your asynchronous NSURLConnections in parallel. The only thing that will stop it is your memory :) I recently implemented a connection pool (my solution was based on NSOperationQueue) just because of that. Now I can control parallel connections and my app doesn't crash when loading hundreds of avatar images.
About your second question. I actually don't know about a way to get the list of current threads. I had a look at NSThread API but no sign of an API for that..
So the reason I assumed there may be a simultaneous connection limit at the mobile OS level is because many mobile browsers enforce one. There are techniques for speeding up loading speed of the mobile version of your website by ensuring that there are as few additional content fetches as possible. Images are the main culprit, but css files, javascript files, etc all require an additional connection.
In mobile, setting up and tearing down a connection is much more expensive than a single connection with more data, and one technique for improving page load performance is embedding your CSS and javascript in the page itself.
It sounds like this limitation may not exist in the OS itself, at least on the iphone platform.
As far as an answer to this question, I found this post that discusses the practical limitations of simultaneous connections. It's not a hard limit, but I think it answers the point of the question.
Background threads consuming 100% CPU on iPhone 3GS causes latent main thread
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.