Should WP7 edit forms have Save/Cancel buttons or should you use 2 way binding?

Question

This is a question on edit form UI for a WP7 app:

I currently have my edit form fields set to 2-way binding which means that as the user changes them they save on edit and update the UI in the ViewModel (Method 1). So I don't need a Save button and there is no Cancel button (unless you code in logic to store the original state and rollback on cancel).

Method 2 would be to use 1 way binding and UpdateSource on the save button and then you could have a Cancel button which functions like the Back button (goes back without saving).

Method 1 is nice as it handles preservation of state if the app is tombstoned - WP7 will restore the page and your changes will have been saved. The downside is that there is no way for the user to restore it to it's starting state once they make changes. My form is trivial so I do not think this is a problem. The Back button acts as Go Back.

I also do calculations in the setter property in my VM that need to be reflected to the UI (ie you will in Field 1 and Field 2 is double the value (but they can also override it) - I use 2 way binding on Field 1 and update field 1 and 2 on edit. I can't think of a way to do this using explicit updating.

The problem is that I have a Delete button for the record, so when I use Method 1 with no Save and Cancel button the user is likely to click the Delete button as it is the only available option (they need to click on the Back button to go back).

My question is; should a simple form have a Save and Cancel button and commit the data only on Save, or is it ok to use 2 way binding and have no buttons?

Answer 1

Parts of this are mentioned in the UI Design and Interaction Guide page 68.

Changes to Application Settings should be immediately implemented. This means that a “Done”, “OK”, or other confirming dialog is not needed.
...
If a task cannot be undone, always provide the user with an option to cancel. Text entry is an example.
Actions that overwrite or delete data, or are irreversable must have a “Cancel” button.

As for your situation you will need a confirmation for the delete action (see the ie settings for an example). For your other fields check the guide as other issues are mentioned and you could also see how the built-in settings work.

Answer 2

If it is possible that the user may ever not want to have their entered text changed it'll be easier to have a one-way binding and update the saved value only when the user specifically says to.
Yes, this can make the preservation of entered data slightly harder during tombstoning but means that it's easier fro the user to be able to change their mind.

In your situation, I'd recommend having on screen buttons for Save and Delete (and relying on the hardward back button for cancel).