[smw]

In the old design, I had to create a clone of every song in the setlist, and clone all of the annotations, then while saving, I'd clear out all of the existing annotations, rebuild all of the annotations in the database, then replace all of the annotation lists in all of the original songs with the lists used in the editor. It's not that I can't support this with the new design, I just didn't want to go through the effort if there wasn't a convincing need for it.

You are correct - in addition to the original file being modified with snippets (which can't be canceled unless I made a copy of the file and replaced it as described previously), the auto-save feature wouldn't really work if I couldn't modify the database. One of the things that could happen in the old version is that users would lose changes they made either due to power running out, or the app being forcefully killed without saving, or anything along those lines. I wanted to prevent this loss of time and work if possible, so I added auto-saving.

If I get enough users requesting the ability to cancel, and there are good arguments for it, I can consider supporting a cancel option. I just think most of the time, it's not necessary, and having to explicitly click "save" is something I wanted to avoid. Now if users exit the annotation mode in any fashion (including just hitting the back button or a three finger tap), they don't have to worry about saving or canceling their changes - they are just saved automatically. 

Mike

I'm not sure whether you're replying directly to me here, or to Palosanto, but just in case:

I can see why you wanted to change the design!  But having said that, I find it difficult to imagine losing changes due to running out of power, if only because it doesn't make sense to start editing if the battery is that low to begin with.  I've been using MobileSheets since late 2012, and I never once ran into a situation where the app was killed by anything other than my choosing to exit.  Still, I can't disagree with wanting to be careful!

I can't give you a good reason why a cancel option is necessary; I've definitely had situations where it was very useful, but it's been a while and I can't remember the details.  Right now I can't think of any situations that would apply to me in which an option to undo all changes made in the current session wouldn't be just as good as an option to cancel the session; the two aren't identical operations, but the result is close enough to identical for my purposes (and if that ever changes I promise I'll give you details :-).