If you are making your application real-life-proof you will also have to deal with diminished or dropped connectivity. I already discussed how to detect the kind of connectivity your app is having at present.
But another real-life restriction stems from slower bandwidths available over cellular connections, especially if you have no 3G reception. Even Long of Scribd showed me this trick I am about to explain here. This enables you to artificially create a bottleneck on your connection so that you can test how the app behaves when only cellular bandwidth is available.
This helps you to see if your custom progress bar is showing nicely or possibly if your progressive image is indeed progressive. Also this might reveal synchronous URL loading operations that you should never ever do in production apps.
I would expect for Apple to add this artificial bandwidth limiting to iPhone Simulator, but until they do you heres a method to achieve this yourself. This is my regular network connection, please don’t laugh if you are used to higher speeds.
Now our trick creates a new IP firewall rule restricting the bandwidth to 112 kBits. You have to do this modification as root, hence the sudo and the first sudo will ask for your root password.
sudo ipfw add 500 pipe 1 ip from any to any sudo ipfw pipe 1 config bw 112kbit/s plr 0 delay 20ms
The same speed test shows the much decreased connectivity:
Now you can test your app in simulator and enjoy the much faster turnaround when debugging the handling of slow connections.
To remove the firewall rule you use the following command:
sudo ipfw delete 500
This is a very handy trick to have in your arsenal. As I said many of the usability problems of production apps result from synchronous network operations as well as not having though through how to deal with slow connections. But these are a fact of life, so you better make sure that your apps can deal with them gracefully.
Update, a few minutes after the first post …
Now having so many smart readers of this here blog also means that often they know of smarter ways to achieve the same things. If you have Charles Debugging Proxy you already have a speed limiter built into that.
Another alternative that four people recommended independently is the speed limit preference pane by Mike Schrag which has the added advantage of allowing easy configuring for specific domains.
Both are comfortable alternate solutions, but I can never hurt knowing how to achieve the same thing in termal.
Still, thanks for all the suggestions!