I just thought I’d write a very quick post on the above message which some of you may have seen when syncing your iPhone / iPad with iTunes. Now ordinarily this may be a self explanatory message, however it’s ‘self explanatory-ness’ may very well depend on the file it’s talking about. So for the past month or so, I’d been getting this message when syncing with iTunes…
iTunes could not copy “Phone Calls” to the iPhone <insert phone name> because the file could not be converted.
Immediately over thinking the issue, I assumed this was something to do with the register of phone calls made / received and went looking for a resolution. I didn’t find one. Finally today (after installing iOS5) it occurred to me what’s going on.
The file it’s talking about is an MP3 from an album I have. The file is corrupt and therefore cannot be converted to the 128 kbps AAC format that I have selected in the Summary screen for my phone. It just so happened that the filename looked like it could be related to the system somehow. Duh!
Technology 1 – Simon 0
So right back into the mix after the chaos of Christmas and I’ve come to make version 1.1 of my most recent project. I started out finding a bug which I hadn’t noticed before (or which hadn’t been vocalised until today) which basically spewed out the error (in the title of this article)
It didn’t stop the app from running normally and the issue was fairly easy to track down, though I thought I’d post the solution just in case you didn’t find it anywhere else. Yes… I’m talking to YOU!
Okay so here’s where I went wrong. In my app delegate I instantiate a class to set up my default data for the app. The content of this really isn’t important. However, if there’s an issue with that set up – I had the class show a UIAlertView message and this is what was causing the issue. In the ‘didFinishLaunching’ method of the app delegate where I was calling my class, the view wasn’t yet available. So when the alert came up, it was just before the view was drawn. This is what all the fuss was about.
I decided to fix it by returning a BOOL value from the data set up and then after the window was drawn, using the value to display (or not) the warning. All very straight foward. Not really sure whether it would have caused an issue in a production app – but good to know anyway. Other people online reported similar things, but most related to the order in which things took place.