I’m excited to be presenting at the Rich Web Experience this December. It’ll be a great show, but the venue location simply adds to the magnetism. Who can resist beaches and Florida in December?

I’ll be doing a sharpened version of my iOS workshop with Ben Ellingson. Attendance numbers will be greatly limited compared to our last time we ran this workshop so as to give plenty of one-on-one attention to students. We’ll get to use the latest iOS 4 SDK with its polished UI, developer-helpful features and Git integration. I hope you’ll consider joining us for this special one-day addition to the conference. Ben and I will be tempted to run the workshop on the beach.

I’ll also be doing a Git workshop in the main portion of the show. If you haven’t already heard, Git (and GitHub) is the hot new open source source code control tool that is agnostic to your programming language of choice but adds features driven by developer needs, not by marketing teams. Bring your notebook, see what the buzz is about, and walk away with a Monday-morning-equipped set of skills to apply Git on your next project.

See you on the beach!

What a mistake. With no apps running in the background, Push turned off and Notifications turned off, according to the myWireless AT&T app, my phone is using between 5 and 50 MB of data per night. The usage occurs between 11pm and 3am MT. Upon waking the phone up, it shows it is connected to WiFi, but I get a momentary flicker of the 3G icon. That’s what makes me suspicious it is using 3G instead of WiFi when it goes to sleep. That behavior is contrary to documentation.

Articles and Links

There’s no shortage of material to point at extolling variations of this problem. Some are old — as far back as 2008 — but the post frequency and number of new threads has increased, centered around the iPhone 4 launch and anyone transitioning to a 200MB data plan.

An Apple forum 3+ page post on iPhone 4 using Cellular Data when on standby and connected to wifi.

A MacRumors thread that states “it’s speculated that it’s being sent via 3G because the phone typically is sleeping when this occurs, and iPhone (at least until iOS 4.0) never connects via WiFi while asleep – only via 3G”

The 10 page Apple discussion entitled “Unknown data usage early morning”.

An AT&T forum thread entitled “iphone 2am unauthorized data usage”

Another AT&T thread from 2009 stating similar complaints on iPhone OS 3.0

A claim that it is just a usage tally (which still doesn’t explain the days I never leave the office WiFi).

“iPod touch can stay connected to Wi-Fi when asleep so you can receive incoming VoIP calls and notifications from compatible third-party apps.” So, WiFi should stay connected.

“There’s no word on whether this applies to the iPhone as well (since cellular data is typically persistent anyway), but it would be a nice feature to have in all iOS devices — including iPad, especially when roaming with data turned off, or even just to prevent the delays that usually accompany reconnecting to Wi-Fi based remote control apps.”

Older, 2008 post claiming “Wi-Fi is usually turned off a little while after in standby.”

Conclusion

The only logical explanation is that everyone is just holding it the wrong way, thereby causing it to use more data on 3G than it should.

.

Sometimes things just don’t go perfectly in the open source world. There are times where it seems like a dot release cures many things, but then breaks/regresses several important ones as well. Like the XML parsing in the iPhone demo. Turns out, it was a Grails 1.1 issue (which I upgraded to from 1.0.3 to solve another bug) in which optional URL parameters are wrongly required. Grails 1.1.1 fixes it, which I validated at 11pm last night, but it would have been fun to live fix this with the audience. This reinforces the point in my talk though that you should always check your web services, possibly using curl, or SOAPui prior to connecting your iPhone application to them.

It’s amazing to see how many of the presenters and audience members are on Twitter and posting their experiences about the conference. That’s a real change from last year, where hardly anyone was live posting in that fashion. I hope to see you all again in the Fall at the next Denver NFJS, loaded with more difficult questions and an inquiring state of mind.

Today’s problem solving summary:

1. XCode projects cannot have commas anywhere in the path up to the location where they are stored or else you’ll get an error message of:
   ld: -filelist file not found: <Project Path>

2. All RESTful web services called via the NSURLConnection APIs must return a non-null payload.

   This bit me because my “Add Contestant” function was adding the contestant and returning void. I now return a string of “Success” to satisfy this requirement. The observable failure is very quiet, which made it so hard to debug; every other web service call appears valid, but never actually makes a call across the wire. This was proven via TCPDump. All the web service call callbacks are properly called in the Objective C side of the program. It just silently failed and passed back a null payload in the response data structure.

All the code for this project is available on GitHub and will be updated with the results of the adjustments based on the above findings by tomorrow.

Also, here’s a link to my iPhone tagged Delicious bookmarks.

iPhone Development Mind Map by Matthew J. McCullough is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Hello Matthew,

This is a follow up to Bug ID# 6503844. After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 6548496.

Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs.

The part that is odd is that the “Original Bug ID” is a larger number than mine. I was pretty sure that the bug IDs were sequential. Perhaps not.

This particular call appears to have been leaking since I first jumped on board iPhone SDK development over a year ago. Let’s hope it becomes a priority in a soon-upcoming release of the software and SDK.

Still, on the whole, development on the iPhone is awesome, and if you are in Minneapolis, Seattle, or Denver, I’d be pleased to have you in the audience at the NFJS talks.

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:

1. SOAP Service Calls on the iPhone
2. Stack Overflow thread on Cocoa Web Service Access
3. Apple iPhone Dev Center
4. A Blog about 5 languages calling web services, including Objective-C
5. A continuation blog post specifically on Objective-C and REST
6. And a download of a sample client in Objective-C that calls REST methods
7. UPDATE: SeismicXML leak discussion
8. UPDATE: MacRumors sendSynchronousRequest leak discussion
9. UPDATE: NSXMLParser leaks too