...
- If the user registers to FCM after the message has been broadcasted then the new user will not get the notification that was sent before. The solution for this may be, the server can run a cron job for repeatedly sending messages
...
Discussion -
- There will be tenant/channel based topics subscribed by the client.
- By default, all clients subscribe to one topic.
- And below will be the structure of payloads.
...
{
"actiontype": "non-display",
"notificationtype": "enable-feature/disable-feature",
"notificationid": "1235",
"expiry": "34646millis",
"data": "free form string data"
}
| Code Block | ||
|---|---|---|
| ||
{
"id": "", // integer number
"notificationtypetype": "", // downtime - 1 / others - 2
"notificationidepoch": "", // integer number
"epoch": "", // This will be present only for server notifications, and 2016-08-29T02:40:33+0530 will be the format
"expiry": "", // 600 This will be present only for server notifications and specified in minutes
"cancellablerelative": 0/1, // 1- true / 0 - false
"channel": "", // channel-id This will be present only for local notification and it will be mentioned in integer, which specify number of hours after installation of app
"poster": "", // Image URL for display
"actiondata": "", // Only for non-display action type Action data contains anything that is not present in the above parameters, like is the notification to be displayed or not, can be cancelled or not and any other data to be passed
"translations": {
"en":{
"title": "Welcome to Sunbird!",
"msg": "Congratulations on downloading Sunbird, every child's best friend in their learning journey."
},
"hi":{
"title": "Welcome to Sunbird!",
"msg": "Congratulations on downloading Sunbird, every child's best friend in their learning journey."
}
}
} |
After brainstorming and design discussion, the below JSON structure for notifications is agreed upon.
| Code Block |
|---|
{
"id": 1, // id of the notification will be integer, which will be unique
"type": 1, // Notification type will be integer - Their can different notification types, like DOWNTIME, GREETINGS, NON-DISPLAY and OTHERS
"relativetime": 2, // Relative time will be integer and only for the Local notification to be shown from Mobile side, it will not be present in Server notification and it will be mentioned in integer, which specify number of hours after installation of app, the notification has to be shown
"epoch":"", // Epoch will be present only for Server notifications, and the format of the epoch will be 2016-08-29T02:40:33+0530
"expiry":"", // Expiry will be present only for Server notification, and it will be mentioned in integer, which specify number of minutes after the epoch time, notification expires
"actiondata":{} // action data contains all the information related to type of the notification, like poster url, translations, notification title
} |
The data received in the actiondata will be with respective to the type of the notification, example, if the type is DOWNTIME, the client would expect the keys relevant to the DOWNTIME type of notification.
https://projects.invisionapp.com/share/7BO6N68STCM#/screens/321764335
...