Is Save Button a good idea ?

Dear Xamarin Users,

I'm building my first Xamarin.Forms app. It is an invoice-app for a company.

I have a question regarding the workflow.

Is it good to have a Save-Button on a page that saves the data on the entire page to the database or
is it better to save each change on the page separately ?

The problem with a save button is that the user can swipe back without saving(or forgetting to save) . This could get confusing for the customer.
Saving each action seperately on the other hand , assures every change is saved but requires more coding and slower data entry.

My exemple is creating an invoice. I have a Page where the user has to fill in a customer, invoicedate, remark and can edit/add multiple invoiceitems.
Should I save each action seperately (choosing customer, changing date, adding invoiceitem,...) to the database ? Or should I have a save-button which saves all data at once ?

What are you thoughts on this ?

regards,
Gert

Posts

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    Let's start with a problem. You don't have data on pages. You have data in ViewModels. The page is just a way to interact with the data: See it or change it.

    As a rule, you save every state change as it happens. That way the app can close at any time and nothing is lost.

    If you want the ability to have the user choose to approve or cancel the changes, then you do all your work to a temporary object. when they approve the changes, then you commit that to your database.

  • AsterinexAsterinex BEMember ✭✭

    Hi ClintStLaurent,

    thanks for your reply. My data is indeed stored in my ViewModels.
    What would you do if a user changes for exemple the description of an invoice item. Save(call webservice) directly after the change ? or Collect all changes and Save (call Webservice) everything for all invoicechanges ?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited December 2017

    save every change as it happens. Otherwise the phone could go dead battery and you'd loose your changes.
    Also... You can't really just trust making that web call. What if they loose service while they are working? I tend to save everything locally - and update to servers on a recurring basis if there is a connection. If you get a positive response back from the server, only then do you know you were successful and can delete the local record. Its more work but its robust and compensates for the real world.

  • AsterinexAsterinex BEMember ✭✭

    @ClintStLaurent said:
    save every change as it happens. Otherwise the phone could go dead battery and you'd loose your changes.

    thank you !

    Any other opinions ?

  • seanydaseanyda GBMember ✭✭✭✭✭
    edited December 2017

    @Asterinex said:

    @ClintStLaurent said:
    save every change as it happens. Otherwise the phone could go dead battery and you'd loose your changes.

    thank you !

    Any other opinions ?

    Personally, I update things on a Save button event, For you to be editing text fields and saving on the fly, what event and how many data calls are you sending?

    For example, You're editing your app Profile, You're not going to be firing a data call on the TextChanged event, that would be very resource heavy for a mobile app, and if your battery dies... tough that's life. If you are saving information as you're doing it, the least you could do is on the Unfocus event, but to be fair, as a user I would be looking for a Save button when I've done my changes.

  • AsterinexAsterinex BEMember ✭✭

    Seanyda, thank you for your opinion.
    My Page contains : a Picker for the Customer, InvoiceDate (DatePicker), InvoiceRemark (entry), and a Datagrid where multiple invoiceItems can be added and edited. Each row contains (Name, Description, number of units, price per unit, vat%, total price).

    Indeed, saving each action would require a lot of traffic/programming .
    At the moment I have one big save button at the bottom which sends all data at once to a webservice. The problem is that the user swipes back, all data is lost.

    On the other hand I like the idea of saving actions. But I'm afraid it will slow down the process. Also accidental changes are saved directly. mhhhh ....

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    You're not going to be firing a data call on the TextChanged event,

    You shouldn't be doing that AT ALL. That's very 1998 WinForms and not at all MVVM pattern.

    Indeed, saving each action would require a lot of traffic/programming .

    Unless you're sending photographs every time, how much data could it possibly be...? 100 characters at a time for the majority of your transactions? You'd have more data in transactional overhead than actual data being sent.

    The problem is that the user swipes back, all data is lost.

    Why? Shouldn't be. Are you disposing of the ViewModel your view is binded to?

    Also accidental changes are saved directly. mhhhh ....

    Again... If you want to not commit on each change, and want to avoid accidental changes and allow the user to choose [CANCEL]... clone your data object to a temporary copy. Make all your changes to the copy. When the user selects [COMMIT CHANGES] you save. If they hit [CANCEL CHANGES] you just dispose of the temporary copy.

  • AsterinexAsterinex BEMember ✭✭

    @ClintStLaurent said:

    You're not going to be firing a data call on the TextChanged event,

    You shouldn't be doing that AT ALL. That's very 1998 WinForms and not at all MVVM pattern.

    It is not clear to me what your opinion is.
    1) General Save button
    2) Save each action (like textChangedEvent)

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    2) Save each action (like textChangedEvent)

    If you're doing logic based on UI events like that then you're already going down a bad path. This is anti-MVVM. Bad design. Out-of-date architecture. I can't think of another way to say it.

    It is not clear to me what your opinion is.
    1) General Save button

    As I said before, my apps save on every state/value change. But you have to make a decision about your app. What do you want? What do your users want? Do you want a very automatic feel where the user doesn't have to go through that deliberate extra step? IE: It just works. Or do you want to offer the ability to [Save] [Cancel]? That's your design choice.

  • AsterinexAsterinex BEMember ✭✭

    @ClintStLaurent said:
    As I said before, my apps save on every state/value change.

    How do you do it ? in an event (textchanged) or in the setter of the property ?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    As a command. A property could be set from anyplace, so that's not a valid choice.
    But the command "save" or the command "cancel" can come from valid places such as multiple places of user interaction (a button, and a menu, and a change of listview selection... as well as code logic... a calculation completes, a REST call brings in a new object...

    But you have to remember that a ViewModel can be the backing for 0-n views. UI events like "textchanged" should only trigger UI responses, like highlighting the text. But UI events don't trigger logic execution. Otherwise you have tightly coupled UI and logic and we avoid that.

  • GhostbusterGhostbuster Member ✭✭
    edited November 2018

    Interesting information in this thread. I'm also looking for more information on a proper way to save directly without an extra save button.

    I am wondering how you exactly execute the command on every state/value change? Do you subscribe to the PropertyChanged event of the ViewModel and execute the command within the Eventhandler ?

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited November 2018

    @Ghostbuster
    Save... What? You need to give people a better idea of what you're talking about? Save a picture... A downloaded PDF... ?

  • GhostbusterGhostbuster Member ✭✭

    I will try to give a better idea :-)

    For example, let's say we have an app that has a list of books. To edit the book we show a simple page with 2 Entry controls, title and author. When the users makes changes in one of the controls I would like to save them directly to a local database.
    No extra save button.

    My page and controls are binded to a ViewModel (with 2 properties title and author). In the ViewModel I raise the PropertyChanged event if one of the properties changes.

    How and where would you create/place the part for saving to the database?

    In the App I'm working on now, we first had an extra Button with a Command. I removed the button and added an EventHandler to the Propertychanged event of the viewmodel. But I'm doubting this is the proper way to do this.

  • GhostbusterGhostbuster Member ✭✭

    I will try to give a better idea :-)

    For example, let's say we have an app that has a list of books. To edit the book we show a simple page with 2 Entry controls, title and author. When the users makes changes in one of the controls I would like to save them directly to a local database.
    No extra save button.

    My page and controls are binded to a ViewModel (with 2 properties title and author). In the ViewModel I raise the PropertyChanged event if one of the properties changes.

    How and where would you create/place the part for saving to the database?

    In the App I'm working on now, we first had an extra Button with a Command. I removed the button and added an EventHandler to the Propertychanged event of the viewmodel. But I'm doubting this is the proper way to do this.

  • JamesLaveryJamesLavery GBBeta, University ✭✭✭✭✭
    edited December 2018

    The problem with doing the save as the user types is that the setter on the bound property is fired every time it changes. So as the user types, the setter is called on every keystroke.

    So assuming that you save as part of the setter (avoiding saving when the setter is called when the ViewModel is initialised of course) this will be incredibly inefficient - DB access on every keystroke.

    So now you have to come up with some mechanism to delay the save (which is a paraphrase of your last comment). I've done similar for the entry control on a search control, to throttle it so that it only does the search after 0.25s of inactivity. But where do you do this? It could go in the setter, but I bet you'll get unwelcome side effects.

    You say you've achieved something which uses an EventHandler on the PropertyChanged event of the ViewModel. I think when you're having to hook in complex new events to achieve something, to put it bluntly you're doing it wrong. Oops, I sound like @ClintStLaurent now! In my experience, if I'm chasing my tail and adding more and more complexity to achieve something which 'should just work', my design is wrong.

    The design where a save is carried out as the user types also means that the user can enter incorrect information into the database with no chance to review.

    At the risk of going back to the start of this thread and the discussion, I'd have a Save button on the page which is only enabled when the data is dirty. This is coupled with checking, when navigating back, whether the data is dirty. If it is dirty, then prompt the user to ask whether they want to go back without saving, or whether they want to save. This is clean and understandable for the user. It's the way we do it in our apps.

    All the above echoes what @seanyda has already said.

Sign In or Register to comment.