When using the Webcom realtime notification function, data updates are shared in real time with every instance of mobile apps that run in foreground on every connected device. However, this operation relies on websockets, which are closed as soon as apps go to background, and so it cannot notify neither apps paused in background nor apps that are not running at all.
Webcom provides a "mobile push notification" function that overcomes this limitation. It makes it possible to notify mobile applications even if they are paused in background or not running at the time of the notification. If paused or not running, applications are automatically woken up or launched before the notification delivery.
Using this feature is quite similar to the realtime notification feature as far as subscription and unsubscription are concerned: you simply have to pass the path of the data node of the Webcom database to watch to a dedicated method of the Webcom SDK. You can also choose the type of event to watch (value change, child addition, child change, child removal) to subscribe to.
However, receiving notifications, including waking up the app or launching it if needed, is quite different, it relies on a third-party mobile messaging service, namely
- Firebase Cloud Messaging (FCM, formerly Google Cloud Messaging) for Google compliant Android devices,
- Huawei HMS Push Kit for Huawei non-Google compliant Android devices (devices with AppGallery)
- or Apple Push Notification service (APNs) for iOS devices (in this case, Webcom actually uses FCM, which in turn provides a relay to APNs).
Once a notification received, the client application is free to display it as a native notification or trigger anything else, typically start a dedicated activity or request the Webcom back end to synchronize some data.
In between, as soon as a subscribed data node is updated, the Webcom back end requests the relevant messaging service (FCM, HMS or APNs) to send a notification to the subscribed mobile devices. Relaying notifications through such a third-party system leads to some specific consequences:
- the activation of the messaging service must be requested outside the Webcom world (generally through a third-party dedicated console), and the resulting configuration must be provisioned into the Webcom developer console ("notifications" tab).
- the mobile device identifier will have to be passed to the subscription API of the Webcom SDK. Getting it fully relies on the messaging service (FCM, HMS or APNs) API.
- the subscription API of the Webcom SDK can be requested to cipher the content of the notifications to be sent.
- contrary to the Webcom realtime notification, notifications sent by the Webcom back end may not include the data updates as messaging services limit the size of messages. In this case (for large data) when the mobile app is woken up, it has to retrieve the actual data by directly requesting the back end.