...
4. There can be other instances as well, where the need for usage of this feature can be used.
Proposed Solution:
- The poll based approach was discarded because the app would poll every time an endpoint and check for the status of the system. It was discarded because it does not provide the handy features as provided by FCM, which is discussed in the below point.
- FCM - With FCM there are many advantages which helps to build our requirement in a handy way -
...
- 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 "type": "", // downtime - 1 / others - 2 "epoch": "", // This will be present only for server notifications, and 2016-08-29T02:40:33+0530 will be the format "expiry": "", // This will be present only for server notifications and specified in minutes "relative":, // 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": "", // 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
https://github.com/ekstep/Common-Design/wiki/Firebase-Cloud-Messaging(FCM)-Integration-with-sunbird
Anil Gupta Swayangjit Parida Mathew Pallan
...