Saving an in-edit object state permanently


#1

Imagine the user - working away in the middle of your application, editing some complex object and before he can hit Save (or commit, or done, or whatever) decides to hit the Home button instead. On Page 464 the authors suggest we should commit those unfinished edits as if the user had intended to save them. Yes, I know - it’s just a book, it’s meant to be an example of what you could do and isn’t necessarily a suggestion of what you should do, but I got to say - any programmer that suggested we commit a user’s actions for them, on their behalf… well, that’s just not good design.

Thoughts?

Mark H


#2

I disagree with your assessment. We aren’t really committing anything on the behalf of the user that they could “avoid”. Let me explain by looking at the two use cases, editing an existing item and creating a new item.

  1. Editing an existing item - If you edit an existing item, there is no way to “undo” your changes. Although the changes aren’t committed until the user hits the back button, there is no way for a user to “cancel/undo” the changes they’ve made to the item without re-typing the existing values. So our decision to save the changes to the store doesn’t impact anything here.

  2. Creating a new item - The logic here is is essentially the same as above. When creating a new item, we “save” the item so the properties persist. When the user comes back to the app, they can “Cancel” (which deletes it from the store), or they can “Save” (which of course then takes any changes they’ve made and saves them to the store as well).

In other words, everything we are doing is transparent to the user. The existing behavior stays the same. Does that make sense?