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
Related
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
I have some code that runs slowly when I test it on an iPhone 4. I am thinking about researching Grand Central Despatch and using a background thread for some tasks. However, I understand that the iPhone 4 is a single core device. Does this mean there will be no benefit on this device to using a background thread?
I couldn't find much in Apple's documentation about different device capabilities in this regard and am new to background processing.
Yes as long as its running iOS 4 or later. GCD is a good design in that it can be used equally well on single core machines all the way up to 16 Core Mac Pro's. In fact Apple emphasized this when they introduced GCD. If your code is well written it should work equally well on a single core iPhone as well as multicore iOS Devices out there. Theoretically you should see performance improvements on multicore devices over the single core devices.
It all depends what your code is actually doing. If your code is targeted to calculate only one thing without stopping there is no benefit of using multithreading on one core cpu in terms of performance. If however some of your tasks are waiting for something like network data, waiting on disk operation, sleeping etc. then your other threads might be using that time to do something useful even on one core cpu. Generally if you are interacting with UI then it is recommended to do time consuming tasks in background so you won't block user interface thus providing better experience for the end user.
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.
What is the biggest limitation of making/using webapps?
I'm thinking that when you use localstorage, offline-browsing and geo-abilities thaht you get from html5 the differences are quite small (except for games).
The great benefit from using webapps is that they are cross-platfrom compatible!
One of the biggest limitation is access to hardware. You can't access USB ports, specialized hardware you might have (printers, bardcode readers), and other stuff, and of course, you don't have access to some very important APIs that you need today to run games (DirectX, OpenGL).
But I agree: every day they are fewer reasons to not go with a WebApp instead of a Native APP.
For iOS: When using geolocation for webapp, the user will get prompt about giving location access every time, which could be annoying for the user. Native app, only the first time.
The UI performance is also not as smooth as native. Scrolling in webview has a "slower" acceleration compared to native view scrolling.
Performance is one major difference. I see from around 20X to over 200X speed improvements when converting from Javascript to compiled C/Objective C code. One can also do real-time audio and video processing in native code, as well as low-level networking, etc.
One interesting limitation (HTML5-wise) I see is from a point of intellectual property. Since a lot of code (raw JavaScript + HTML) is exposed to the user, you have to carefully decide which components will be "open" to end users. Not aware of any standard way to lock or hide your IP once it leaves your server.
Webapps are great for reaching multiple hardware devices, you can update your app a lot faster, thus feedback is quicker. However, your users will require an always-on internet connection to use your webapp, that's probably the biggest negative about them in comparison to a native (offline) app.
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 :).