Question

I’m using MonoTouch and also System.Data to create a DataSet (just xml to those not familiar) for simple data binding. Data on my app is minimal so no need to go all out with SQLLite. The dataset use makes it easy to pass via web services for cloud sync.

I serialize the DataSet to the personal folder on save and of course read this file when the app starts up to load up the user’s data. I’ve had issues where this file is becoming corrupt and I’m not sure why. I assume file I/O may be slow on these devices and that could be the cause, I’m not sure, but it is happening.

I’m also concerned that maybe iTunes is passing this file back and forth between the PC/MAC when the user syncs their devices with iTunes, which may be the cause of the corruption?

I want to prevent this device file from syncing with iTunes and also reliably persist it. I’m using the NSFile.Save option to save it to the device. I’m thinking since it’s a text file maybe I could more safely store it in the standard user settings area instead? This would prevent it from being synced by itunes, I presume?

What is the most reliable and safe way to handle this file i/o for the xml dataset storage?

Thank you.

Answer 1

You’re using MonoTouch. Isn’t it simply a matter of calling DataSet.WriteXml() with a FileStream object ready to write to a document in your Documents folder?

That Documents folder is backed up to iTunes. It’s not synced, but it helps if your user is restoring their phone (because they bricked it, lost it, whatever). It doesn’t explain why it’s corrupt.

The only thing that I can think of why it’s corrupt is because it took too long for your app to write it. There’s a limited time from the point where the user exits the app until it’s closed down, to prevent apps from keeping the system hostage and deteriorate user experience.

If writing the whole dataset takes too long, you want to think about minimizing that. Perhaps you can just store the data, and not the schema. Or you can devise a way to store only the deltas on exit and reconcile when the user has loaded your app again.

You can also prevent complete loss of data by writing to a second file, and when that operation completes delete the old file and rename. That way, the next time you start up if the write operation didn’t complete, the old file would still be there and the user would have only lost their more recent changes.

In any case, if your data gets too big for a simple write operation to complete, you should look at different options such as sqlite.