Recently, I gave the second version of my iPhone and Java Web Services talk at the Boulder JUG. It was a great audience filled with interest and great questions. I promised them I would continue to load up my Delicious bookmarks with great iPhone links, and I’m doing just that.

Pertinent to that talk, let’s quickly revisit that memory leak issue for NSURLConnection. In short, if you call sendSynchronousRequest, you get an internal memory leak of 128 bytes of a NSCFString object from inside the API.

To isolate this from my application coding skills via the iPhone and Java Web Services demo code, let’s look at an example called ZipWeather from AppsAmuck. Attach the profile to the ZipWeather, exactly as downloaded. Run it. Type a zip code. It leaks.

It appears that the NSURLConnection:sendSynchronousRequest() Flaking out, even for others, calling this API to Amazon Web Services. I believe it may be the leak contributing to these hiccups. I’ve tried turning off the cache, but it still leaks. I’ve tried the async version and it still leaks too.

This Apple article even suggests using this same API in the same way that ZipWeather and my iPhone and Java Web Services app does.

In short, I’m submitting another Radar report to Apple about this and hope it doesn’t get closed out as “Unable to reproduce” as João Pavão’s defect # 6179277 did. I’m able to reproduce it every time, with everyone’s sendSynchronousRequest calls.

I love the platform, but as you all know, one core API bug can really cause a lot of challenges until resolved. Let’s hope this one gets resolved very soon!

References: