- There is no âbest wayâ I guess, it really depends on your implementation.
-
Here are different ways to store data on the client side, check which one suits you the best. (To me, you shouldnât use local storage in your case for example).
- The payload can be whatever you need, as long as it looks reasonable to pass the data youâre willing to pass in the push (e.g: even if it seems obvious, you DONâT WANT TO send an entire base64 encoded image data here)
I will try to give you an example of what you could (not saying this is the only viable solution) implement in your application, since you seems a little bit lost about how to do it.
First, at the push level in your app, you need to understand that there is 2 different situations you need to deal with:
1. You receive a push when the user is currently using the app
2. You receive a push when the user is not using the app (closed, or background)
In the first case, the callback you defined for the ânotificationâ event will be called, and you can determine that you are in the first case thanks to the data.additionalData.foreground
variable:
push.on('notification', (data) => {
console.log(data.additionalData.foreground); // It will be true
}
});
If you are in the second case, this variable will be false
.
What is interesting here is that it will give you a lots of different situations to deal with depending what is the current state of your app; for example:
-Letâs say we receive a push notification when our user is using the app. Is the user currently on the chat page or an other one ? If heâs not, you probably should display a notification somewhere on your UI (A little red number on your chat icon in your app menu ?); if he is, you can just directly display the message in the chat.
But wait a minute, isnât it what you are probably already doing with socket.io ? I guess it is ! So letâs skip our case number 1. (Assuming that your server knows when your user is active on the app, you are not transmitting the information by using push, but by using your connected socket).
What you are apparently interested in, is what should happen when your user is not in your app and you receive a push notification ?
Well, if your user is going to click on the push notification (on the lock screen or in the notification center), the callback will be called, and you will find yourself in case number 2.
Here are different options, because it is not guaranteed that the push notifications the user clicked on is the one containing the last sent message information (maybe he received 6 messages and clicked on the 4th notification).
So I would suggest you that in any case, when navigating to your chat, you always need to update it and to synchronize it with your server. The push notification data will be just here to help you to display the right information to your user (for example, putting himself on the chat right at the place where is the message corresponding to the push notification he clicked on).
I am not sure that I am very clear in my explanations, dealing with push notification at the client side being way more complex than it may look if you want to give your users a good UX.
The thing is, depending on the way you implement it, there are thousands of different ways to handle the problem.
Also, although not directly related, but since you mentioned it I wanted to give you an advice about storage:
You should not store too much data in the client side. You should maybe store only the last 20 messages the user read, and if he wants to go back in his history, just fetch it by chunks from your server. It is useless to store thousands of MB of chat data, knowing that most of the time users are not going to use them. You shouldnât as well fetch and store data when the user is not using the app, like I suggested just synchronized your chat state with your server when your user is browsing to it.