I’m looking for best practices to solve this hard problem:
My app has a file import / export functionality coupled with Core Data. This means that when I import a file into my app, I create an entry in Core Data and copy this file over to a private directory of the App. Next, I process the file and create a few others out of it for different purposes in the app. These are heavy calculations taking about 0.2 seconds for every file on an iPhone 3G.
This means that I am dealing with some kind of “transactions” while importing. It’s all done using one big FileImportOperation : NSOperation which iterates over all files that have to be imported, and performs the heavy import work on every single file in the list.
The problem is this: Background threads ans NSOperations get killed by the OS in just a nanosecond without prior warning. Only the Main thread gets up to 5 seconds time to quickly save some work and quit.
How can I ensure that I never end up importing a file half-way, leaving the app in a corrupted or trashed state?
From my point of view, the evil problem is that background threads (including NSOperation) get killed right away when the user quits the app, without any chance to clean up. I tried to compensate this by writing the managed object only if all those files have been created and saved successfully (remember: every imported file is duplicated and processed several times in different ways for different things). But I can still end up with an incomplete import, trashing the disk of the user.
My temporary solution to the problem looks like this: The Object that owns the NSOperationQueue registers for the UIApplicationWillTerminateNotification notification. When it receives it, sends -cancelAllOperations to the queue, which flags all the running operations as cancelled.
At this point I’m stuck. Now my NSOperations are flagged as cancelled, but they still have to complete their current internal run loop and stop.
My next idea is to force the Main thread to wait until all the Operations are completed, and then let -applicationWillTerminate: return.
I’m hoping for some pro-advice on how to implement secure transactions to prevent leaving the app in a corrupted state when importing in the background.
Can you perform your import operation in a manner that, if not atomic, is at least restartable? Eg. a file move that is restartable might look like:
Search for and delete all files ‘*.tmp’ in target folder.
Find a file in source folder that needs to be copied – found one ‘data.DB’
Copy file to target folder as ‘data.DB.tmp’
Rename ‘data.DB.tmp’ to ‘data.DB’
On app start, search for and delete all files ‘*.tmp’
Coupled with a transaction-based ‘Core Data’ DB update, (ie. can be rolled back), can this kind of approach solve your problem?
Rgds,
Martin