iPhones and Washing Machines: Limping to the Finish Line
My iPhone 4S had an unfortunate encounter with the washing machine at the weekend, which amounted to about 20 minutes of water exposure – not to mention detergent, and whatever goodies conditioner contains [for that softer, fresher smelling iPhone!]. We tried the recommended bag of rice trick for 24 hours, which didn’t work. When I opened it afterwards it was still soaking wet, and the battery was leaking. I took out the motherboard and dried it off, and spotted some corrosion on the camera connector. Clearly, any recovery from the condition it was in was going to be a borderline miracle, but I thought ordering up a new battery was worth a shot.
I duly replaced the battery tonight [all told about 2 1/2 hours worth of fun – it’s late!] and, rather surprisingly, it booted up with iTunes presenting me with a request to unlock the device. Rather less surprisingly, the screen doesn’t work. I did a bit of searching to find out which connector was for the screen data [I can find no others that drive the screen in any separate way], and spotted a serious amount of corrosion which I either missed at the weekend, or which has subsequently appeared. Here’s a macro shot before I cleaned it with a toothbrush:
…and after. Magnification is slightly better with this shot because I used a cheap and nasty extension tube:
In the top right, the third contact from the end appears to have completely corroded. While it may not be the only damage stopping the screen from working, it’s got to be part of the problem.
I was planning on upgrading to whatever Apple releases in the next couple of months anyway. In the meantime, I have the dubious pleasure of a Nokia clamshell from the previous decade. I’d forgotten what a joy predictive text was :).
GeoFencer – Update
I’ve fixed a bug that was having a fundamental impact on reliability. I mentioned this in my initial post about the release, and did some more digging. When the device is under resource pressure, the operating system can intervene and kill off apps. My understanding of the registering for location data isn’t a true background mode, and this is quite deliberate in order to minimise resource consumption. Assuming that the app is suspended, the operating system will make a decision on which apps to send the location data to via the appropriate delegate based on the registered mode in the plist file. At this point, the app will launch in the background, and you have a short amount of time to process. [I think it’s at this point that the OS can tidy up based on resource constraints.] Before hitting the location oriented delegate, didFinishLaunchingWithOptions is called, at which point you can check for a prior termination through:
if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])
at which point I restart the location and region monitoring, based on a recommendation here. This does raise the question as to why you need to restart the location monitoring, given that the app is identified as wanting to receive location data in the plist. Having to register in code introduces volatility, which has to then ride through the various running mode changes. Perhaps it’s to have convergent functionality [and readability] with doing the same in the foreground. Either way it works.
One other change in the AppDelegate is that I no longer use the same property based UILocalNotification. If more than one delegate is hit on restart, trying to use the same notification will cause an error.
I’ve also noticed a ‘feature’ in the GeoFence creation view controller. I thought it would be more elegant to automatically save the location data based on the pin drop event rather than a hard-wired button, as the map is already cluttered. One downside of this approach is that changing the radius of the region after the pin is down updates the screen but isn’t saved. It would be a relatively simple change to make but I’m toying with the idea of a podcast app [using some of the new background features].

