I am developing an application which does a lot of API fetching and it happens, if the internet connection is very low, say 5 kbps the app crashes in the main method.
I think it happens when a lot of requests are in the queue so the OS terminates the app.
I am using ASIHTPPRequest and asynchronous block-based requests.
How can I solve the problem?
You would need to use a Single network queue for the whole app. Apps that depend heavily on Internet connectivity should optimize the number of concurrent network operations. Unfortunately, ASIHTPPRequest framework does not do this. I would suggest you use MKNetworkKit which has been built especially keeping mobile apps in mind.
Most mobile networks (3G) don’t allow more than two concurrent HTTP
connections from a given IP address. Edge is even worse. You can’t, in
most cases, open more than one connection. This limit is considerably
high (six) on a traditional home broadband (Wifi). On any normal case,
the iDevice is mostly connected to a 3G network, which means, you are
restricted to upload only two photos in parallel. Now, it is not the
slow upload speed that hurts.
The real problem arises when you open a
view that loads thumbnails of photos (say on a different view) while
this uploading operations are running in the background. When you
don’t properly control the queue size across the app, your thumbnail
loading operations will just timeout which is not really the right way
to do it. The right way to do this is to prioritize your thumbnail
loading operation or wait till the upload is complete and the load
thumbnails. This requires you to have a single queue across the entire
app. MKNetworkKit ensures this automatically by using a single shared
queue for every instance of it. While MKNetworkKit is not a singleton
by itself, the shared queue is.
source
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 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!
I've been looking at some very great online services iPhone app, such as the Twitter app. It's very robust, I can't crash the app no matter what I do.
When I try to build one, I always get crashes whenever there's something wrong, like no internet, wrong passwords, etc. Especially I notice that my app crashes when I switch between tab bars too quickly (when one of them is waiting for a response from the Twitter server, for example). How do I elevate this issue?
Is there any tips to build apps that never crashes like Twitter for iPhone?
Crashes tend to happen because of one of two reasons:
You're referencing a deallocated object
You have exceeded the amount of memory that you are permitted to use, either due to leaks, not lazy loading, or just an overall bad design.
As far as Internet connections go, this StackOverflow question has your bases covered there.
It's hard to say why making fast tab bar switches are causing your app to crash without code.
I have written such an app (a shopping app that uses the network for everything). Here are some tips:
Implement reachability so you know when the network is there (and keep checking it)
Run all network access asynchronously so the app does not freeze, thread networking when you can.
Send and receive the smallest amount of data per request. For example, in my shopping app, I only get 50 products per search, with only the SKU, description and price. Use JSON.
Round trip - request network data - as infrequently as possible, and at most once per screen. If you can do with the data you have in memory, do so.
Lazy load images
Cancel all network connections as soon as possible. As soon as the tab changes, kill any outstanding network access.
Cache, cache, cache. Its always quicker to get data locally.
Hope this helps.
One big differentiator between great network apps and terrible network apps is handling network latency. I can't stand apps where the UI stalls or becomes jerky when data is requested from the network, or where the entire interface is frequently locked up with an activity indicator. I tend to quit and uninstall these types of apps right away. Sometimes it is not entirely obvious how to allow the user to continue interacting with the app when some data is required from the network, but the hallmark of great design is that you think about these issues ahead of time. Really, those lengthy stalling activity indicators are a big "fail!" in my book.
I'm writing a network-data-heavy app myself, and implementing a really simple URL image cache singleton class and a "lazy" subclass of UIImageView that loads images in the background using an NSOperationQueue was really pretty simple, and the app runs smooth as glass :).
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.