Page MenuHomePhabricator

Update badge count from JS on native taking into account thick threads
ClosedPublic

Authored by marcin on Aug 28 2024, 3:12 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Oct 13, 12:51 AM
Unknown Object (File)
Thu, Oct 10, 12:49 PM
Unknown Object (File)
Thu, Oct 10, 12:49 PM
Unknown Object (File)
Thu, Oct 10, 12:49 PM
Unknown Object (File)
Thu, Oct 10, 12:49 PM
Unknown Object (File)
Thu, Oct 10, 12:49 PM
Unknown Object (File)
Thu, Oct 10, 11:47 AM
Unknown Object (File)
Tue, Oct 1, 4:00 AM
Subscribers

Details

Summary

This differential uses JSI from previous differential to update badge count by taking into account unread thick threads. The algorithm is the same as for the keyservers:

  1. If we are connected to the tunnelbroker, we trust redux and update notifs storage (MMKV) with data from redux.
  2. If we are disconnected from the tunnelbroker, we trust notifs storage (MMKV) and fetch data from there.
  3. We sum the number of unread thick threads and partial unread counts for each keyserver to get the total unread count.
  4. We set badge count to total unread count.
Test Plan
  1. Apply this patch: https://gist.github.com/marcinwasowicz/35071cea6abade632df8bc30f71fb1ab to send messages and rescinds to native device from web.
  2. Ensure that badge count stays consistent both in the background (notifs code modifies badge count) and in the foreground (JS modifies badge count)

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

marcin edited the test plan for this revision. (Show Details)
tomek added inline comments.
native/push/push-handler.react.js
831 ↗(On Diff #43728)

What does bound mean in this context?

This revision is now accepted and ready to land.Aug 29 2024, 6:27 AM
native/push/push-handler.react.js
831 ↗(On Diff #43728)

I was following the naming convention for other variables: boundUnreadCount and boundConnection.

  1. If we are connected to the tunnelbroker, we trust redux and update notifs storage (MMKV) with data from redux.
  2. If we are disconnected from the tunnelbroker, we trust notifs storage (MMKV) and fetch data from there.

Can you explain this approach in a bit more detail? Why do we trust Redux if (and only if?) we are connected to Tunnelbroker? And why do we trust notifs storage when we don't trust Redux?

  1. If we are connected to the tunnelbroker, we trust redux and update notifs storage (MMKV) with data from redux.
  2. If we are disconnected from the tunnelbroker, we trust notifs storage (MMKV) and fetch data from there.

Can you explain this approach in a bit more detail? Why do we trust Redux if (and only if?) we are connected to Tunnelbroker? And why do we trust notifs storage when we don't trust Redux?

This the same logic that we agreed on during one of our 1:1 in February while discussing unread count for multiple keyservers.

If we are connected to Tunnelbroker then redux will have the latest updates on unread counts which should be more up to date than updates from notifs. If we are not connected to Tunnelbroker then notifs should be more up to date.

Okay, thanks for explaining!