Best practice when saving settings to backend on Android

Question

In my app, I have a settings page with a number of options that all need to be saved on our backend. The call to the backend may fail for connectivity reasons and I'm not sure what's the best way to tackle it. Here are the options I thought about, maybe I missed some:

1. Optimistic individual change

   • Every time a setting changes, call the backend and visually reflect the change. If the backend call fails, show a toast and revert the change.

   • Advantages: seamless, user knows when there's an issue asap

   • Drawbacks: more backend calls, state management can be a pain

2. Pessimistic individual change

   • Every time a setting changes, call the backend with a progress dialog disabling interaction until the call is done

   • Advantages: user knows when there's an issue, easier to manage state

   • Drawbacks: more backend calls, lots of friction

3. Optimistic global change

   • Only call the backend when leaving the settings activity and visually reflect changes. If the backend call fails, show a toast and revert changes

   • Advantages: seamless, one single call

   • Drawbacks: user doesn't know about issues before leaving, has to come back and redo everything

4. Pessimistic global change

   • Only call the backend when leaving the settings activity with a progress dialog disabling interaction until the call is done

   • Advantages: one single call, easiest to manage

   • Drawbacks: user doesn't know about issues before leaving, has to come back and redo everything (I don't want to lock the user in the page if the save fails)

Note that the issues will be related to connectivity most of the time as the app prevents from sending invalid input, so no error messages to display on particular fields.

What would the best practice for this, in particular on Android? I've tried to get inspiration from existing apps with good UX but I can't seem to find a common pattern.

Answer 1

From the user's perspective think about the ideal workflow first. That should be your target. As a user, I need to know the time required for you to save the change in my settings. I do not know that you have a backend processing or not. What are the lag and network response time? That way you establish your target.

Usually, that ideal scenario is an instant reflection of every setting just as when the user does it. That is the best practice. That is our target. That is the approach where the user is agnostic of your implementation. All others are workarounds due to limitations of some or the other kind.

Then we start analyzing the technical feasibilities and reducing the degree of freedom you have in the implementation of that target feature.

There is rarely a magic bullet. If you have servers and responsiveness like Instagram, you can go for the optimistic approach of instantly reflecting every change. For that, the settings should be fairly independent. On the other hand, if you have an enterprise application and your changes in one setting have some cascading impact on other settings, you will need some sort of evaluation time to make sure there are no faults.

Your practical implementation will have both the technical and business constraints. Even though the first one is the best approach, it is not always practicable.