Reputation: 4436
My app allows for a text file to be emailed to other users with or without images and audio. When there's no images or audio, then the app sends the text file "as is" with a custom extension (e.g. text.xxx). When there's audio and images, the app zips the text file along with the images and audio into a file named something like text.xxx.zip.
Prior to iOS 6 this worked fine. Pre iOS 6, the app was given the URL of the text.xxx.zip file. Now, with iOS 6, it appears that the file is already unzipped by Mail, and only the text.xxx is sent to the openURL handler.
Does anyone out there have any experience with this? Suggestions for a better approach? I'm thinking I'll need to come up with a unique extension for the zipped case...
Upvotes: 2
Views: 431
Reputation: 4436
So after pounding my head on this for the last 24 hours or so, this is what "solves" the problem:
1) Change any existing attachment filenames from test.xxx.zip to test.zip. It looks iOS6 Mail is assuming that anything of the form filename.xxx.zip, is really just a compressed version of filename.xxx. (Maybe that's a standard somewhere?) Also noted that if I changed the filename to test.yyy.zip it then said it couldn't open the attachment. (presumably since no one registered for the ".yyy" extension).
2) Rewrite code to not use .zip extension in the future to prevent similar issues.
I also discovered that for multiple document types (e.g., .xxx, .zzz) you must specify a different mime type for each in the UTI declaration - otherwise Mail appends the first UTI extension it finds to the object and then calls openURL. So, in other words, if you're set up to handle a flat file (.xxx) and a zip file (.zzz), but you use the same mime type (e.g. application/myappname) and "xxx" is defined first, when openURL is called for your file "test.zzz", it will actually pass it to openURL as "test.xxx".
Upvotes: 1