It is absolutely disgraceful – disgraceful – that Apple has let a significant iPhone library component remain uncorrected for a couple of releases now.
The component in question is the NSURLConnection class; specifically, making synchronous requests.
What’s the problem? Only that a synchronous call leaks 3.5K each time invoked.
And before you weisenheimers chirp in and say to use Asynchronous calls instead, that isn’t an answer.
There are times blocking calls are required, and to avoid the issue is a total cop out (Me: Doctor! Doctor! It hurts when I do this! Doctor: Then don’t do that).
It’s challenging enough working with a device architecture where not cleaning up after yourself vis a vis memory management has extreme consequences (i.e., out of memory and your app shuts down toot sweet).
It’s doubly hard when iPhone libraries from Apple are buggy.
And this is a significant bug.
How many iPhone Apps need to make blocking http calls? A butt-load, that’s how many.
While the eye candy of the iPhone Cocoa Touch environment gets a lot of oohs and ahs, there are a lot of holes like this one that are quite frankly a royal pain in the ass.
Like the non-support for XPath on iPhone devices (yeah, yeah – I’m using NSXMLParser. It’s a lot more trouble than loading a DOM and doing an XPath query.)
We’re not talking world peace here.
But we are talking about real problems in the underlying code from Apple that has a direct adverse affect on commercial apps in the iTunes App Store.
So, the next time one of your favorite iPhone Apps mysteriously craps out (like the Facebook App did to me while composing a lengthy reply), don’t be so quick to curse the developer.
OK. Got that outta my system.