Bugfix remove badge code

[bannzai]

Abstract

バッジを消している関数が過度に共通化されていたのでバラした

Why

元々はバッジが消えないという問い合わせからの調査だったが、手元で再現しないのと問い合わせのログを見てもいまいちわからなかったのでリファクタリングする程度にとどめた

Links

close: #625
これは不要

Checked

• Analyticsのログを入れたか
• 境界値に対してのUnitTestを書いた
• パターン分岐が発生するWidgetに対してWidgetTestを書いた
• リリースノートを追加した

[bannzai]

根本的な原因はbatch.commitを待ってremoveBadgeをしていたが、それだとUIが更新(オフラインDBの更新時)された後にbatch.commit経由でのオンラインDBの更新を待っている間にラグがあり、ユーザーは 書き込みは終わったがバッジが消えない と認識したため問い合わせが発生していたもよう

• オフラインキャッシュが有効の場合は、DBのデータのアップデートが完了する前にSnapShotListenerのイベントが更新される。厳密にはオフラインのデータの更新が完了した時点でSnapShotListenerのイベントも更新される。また、その後にオンラインのデータが更新された後にもSnapShotListnerのイベントが更新される
  • SnapShotのMetadataに Local or Server が更新されたかを判断できるプロパティが生えているので必要ならばこれを使う
    • https://firebase.google.com/docs/firestore/query-data/listen
    • Retrieved documents have a metadata.hasPendingWrites property that indicates whether the document has local changes that haven't been written to the backend yet. You can use this property to determine the source of events received by your snapshot listener:
  • ただ、database.set(data, {merge: true}) を awaitしているときに、実際にsuspendを終えるのはオンラインデータの書き込みが終了した時。なので、オフラインのデータ更新 → SnapShotListenerが実行される → UIの更新 → オンラインデータの更新 → UIの更新 という順序を辿ることがある。困るのがオフラインのデータの更新の後にUIが更新されるとユーザーが処理完了したと認識してしまうところ
• WriteBatch#commit の書き込みが遅い
  • 複数のドキュメントのbatch write が数秒かかることがある。すぐ終わることもある
  • これによりawait database.set(data, { merge: true }) で await していると後続の処理が実行されるのが遅れる。例えばSnackBarの表示やバッジを消す処理