Description
A notification will show up, but when the app opens, assuming it doesn't have to load the whole conversation, it will take it's time to actually load the message, all the while showing the "new message" banner at the top.
This happens because the platform-native code that handles notifications doesn't interact closely with the JS code running on RN which drives the bulk of the app; and in particular, the notification doesn't cause the main app code in JS to wake up at all or to add anything to its storage. So if the app is in the background and not getting to regularly poll (or long-poll) the server for updates, then it won't learn anything about the notification-related messages until the app is launched and it goes and updates all its data.
It'd be good to take a notification as a prompt that we should go refresh our data. After all, it's likely the user will follow the notification.
Schematically, I think the solution will look something like:
- When we get a notification, schedule a background task to wake the app and have it poll the server.
- For a simple version, that task just causes a normal
/eventspoll. - Better, it should also fetch messages in the particular conversation the notification was in.
The exact shape of "schedule a background task" will be based on the Android and iOS SDKs respectively, and we'll want to look up and follow the relevant upstream guidance for each platform.