Skip to content

Push Notifications

There are 3 options to be notified of new events:

  • Periodically fetching notifications
  • Supporting push notifications (e.g. UnifiedPush + optionally fallback to Google notifications aka FCM, Firebase Cloud Messaging)
  • Keeping a constant connection to the server

Depending on your application, it may make sense to support several options. For example, for a social application, some users may want to be informed at most every hour, and others „in real time“.

Periodically fetch new messages

If it's acceptable to have a certain delay before being notified, a periodic task works well. For example, this is how F-Droid checks whether updates are available.

This may also be a good solution for users that rarely use an application and are OK to get non-instant notifications. Or for a mail client, where a little delay (usually) does not hurt.

Push notifications

UnifiedPush is an open standard for push notifications that rely on web push. It allows having efficient „real-time“ notifications:

  • The application will use the service the user has installed
  • One service keeps a connection for all other applications
  • You don't have to implement a constant connection to the server
  • There are several libraries implementing UnifiedPush for app developers

Web push is another open standard, defined by 3 RFC, commonly used for web applications. Your server may already support it.

Furthermore, as explained in the blog post about push for decentralized apps, it is possible to get a fallback to Google Services, that works:

For some Background on UnifiedPush, see:

This solution works well for everyday users, and for occasional users. For the client side, a list of available distributors can be found e.g. in the IzzyOnDroid app listings.

Keeping a connection to the server

Quoting Jeroen:

There's multiple options for getting push*, there's xmpp which works for push*, an MQTT system works, Server Sent Events is an Http standard for this, and websockets is also often used for this. Tutanota and mastodon seem to like SSE, while telegram and signal use websockets in their FOSS environment (but use google whenever possible)

Conversations / Kontalk just uses the xmpp protocol it uses for chat for push notifications* as it's a realtime protocol anyway

* Here, push is used to refer to solutions that allow you to maintain a connection with the server to find out when a new event occurs. This is generally not what push notifications are about. Note however that Conversations can act as a distributor for UnifiedPush (see below).

Keeping a connection requires implementation of the service, a means of restarting it in the event of failure, network callbacks, etc. This will also increase your application's battery and data consumption. This solution is suitable for applications that require „real-time“ events, such as instant messaging applications, for everyday people.