Closed mwfarb closed 9 years ago
I know we're hoping to avoid calling getNoncesByToken very frequently, and I think we can still do that, but we just need to make sure we cover the following cases.
When to call getNoncesByToken, and it doesn’t matter if the user is logged in or not since we’re only downloading ciphertext in both cases: 1 - On app launch, when badge number is > 0. 2 - On resume coming from background to foreground, when badge number is > 0. 3 - On push arrives when app is in the foreground. 4 - On user manually requests a refresh, by pulling the conversation list all the way to the bottom. 5 - On user manually requests a refresh, by pulling the threads list all the way to the top.
I think we have 3 and 4 already implemented. We'd have to add 1, 4, 5.
This is another effect of the same root cause, but the effect makes it seems that the decrypt process did not work:
This case will probably be gone once auto-decrypt is implemented.
Implement a new functionality enabled by manual gesture in thread view, e.g., scroll down the view to fetch possible new messages from the server.
We are now receiving messages in these cases from @brnunes's fix so I'm closing this. I'll add a new issue for updating the message checking model later in another release to make sure we catch some more rare edge cases when we set the badge number to 0 too early.
When a user reboots the device, has a power loss, or manually kills the app, when push messages arrive and the user launches the app, the app does not contact the server for getNoncesByToken.
This is an important issue we need to close ASAP. We know some users are having this issue, but were having trouble reproducing it. Now, we have a reproducible case related to cold start.