Android
私のアプリには、バックエンドに保存する必要のあるいくつかのオプションを含む設定ページがあります。バックエンドへの呼び出しは接続性の理由で失敗する可能性があり、それに取り組むための最良の方法は何なのかわかりません。ここに私が考えたオプションがあります、おそらくいくつかを逃しました：
楽観的な個人の変化
設定が変更されるたびに、バックエンドを呼び出し、視覚的に変更を反映します。バックエンドコールが失敗した場合は、トーストを表示して変更を元に戻します。
利点：シームレス、ユーザーは問題が発生したときにすぐにわかる
欠点：バックエンド呼び出しが増える、状態管理が面倒になる
悲観的な個人の変化
設定が変更されるたびに、呼び出しが完了するまで、対話を無効にする進行ダイアログでバックエンドを呼び出します
利点：問題が発生したときにユーザーが把握できるため、状態の管理が容易
欠点：バックエンド呼び出しの増加、多くの摩擦
楽観的なグローバル変更
設定アクティビティを終了するときにのみバックエンドを呼び出し、変更を視覚的に反映します。バックエンドの呼び出しが失敗した場合は、トーストを表示して変更を元に戻します
利点：シームレス、1回の呼び出し
欠点：ユーザーは離れる前に問題について知らないため、戻ってすべてをやり直す必要があります
悲観的な地球規模の変化
呼び出しが完了するまで、対話を無効にするプログレスダイアログで設定アクティビティを終了するときにのみバックエンドを呼び出します
利点：1回の呼び出しで、管理が最も簡単
欠点：ユーザーは離れる前に問題について知らないため、戻ってすべてをやり直す必要があります（保存が失敗した場合にユーザーをページにロックしたくない）。
アプリは無効な入力の送信を防ぐため、ほとんどの場合、問題は接続に関連しているため、特定のフィールドにエラーメッセージが表示されないことに注意してください。
これには、特にAndroidのベストプラクティスは何でしょうか？優れたUXを持つ既存のアプリからインスピレーションを得ようとしましたが、一般的なパターンを見つけることができません。
ユーザーの視点から、まず理想的なワークフローについて考えます。それはあなたの目標でなければなりません。ユーザーとして、設定の変更を保存するために必要な時間を知る必要があります。バックエンド処理があるかどうかはわかりません。遅延とネットワークの応答時間はどれくらいですか？このようにして、目標を設定します。
通常、その理想的なシナリオは、ユーザーが行うすべての設定を瞬時に反映したものです。それがベストプラクティスです。それが私たちの目標です。それが、ユーザーが実装にとらわれないアプローチです。その他すべて一部またはその他の種類の制限による回避策です。
次に、技術的な実現可能性の分析を開始し、そのターゲット機能の実装における自由度を減らします。
めったに魔法の弾丸はありません。 Instagramのようなサーバーと応答性があれば、すべての変更を即座に反映するという楽観的なアプローチをとることができます。そのため、設定はかなり独立している必要があります。一方、エンタープライズアプリケーションがあり、1つの設定での変更が他の設定に連鎖的に影響を与える場合は、障害がないことを確認するために、ある種の評価時間が必要になります。
実際の実装には、技術的な制約とビジネス上の制約があります。最初の方法が最善の方法ですが、常に実用的であるとは限りません。