A client should implement local notifications to offer notifications for any event in the app without the privacy cost and dependency on third party services. This means that the client should run a background service to continuously or periodically check for updates.
Android allows running services on the device. When the user enables notifications, the client may start a ``Foreground Service`, and display a permanent notification indicating that the service is running, as required by Android guidelines. The service will simply keep the app from being killed by the system when it is in the background. The client will then be able to run in the background and display local notifications on events such as receiving a message in a one to one chat.
To facilitate the implementation of local notifications, a node implementation such as
status-go may provide a specific
Notifications are a separate process in Android, and interaction with a notification generates an
Intent. To handle intents, the
NewMessageSignalHandler may use a
BroadcastReceiver, in order to update the state of local notifications when the user dismisses or tap a notification. If the user taps on a notification, the
BroadcastReceiver generates a new intent to open the app should use universal links to get the user to the right place.
We are not able to offer local notifications on iOS because there is no concept of services in iOS. It offers background updates but they’re not consistently triggered, and cannot be relied upon. The system decides when the background updates are triggered and the heuristics aren’t known.
Push Notifications, as offered by Apple and Google are a privacy concern, they require a centralized service that is aware of who the notification needs to be delivered to.
Copyright and related rights waived via CC0.