The primary goal of this spike was to discover if we could (from a technical level) leverage local user notifications to supplement our incoming push notifications in order to create separate more granular notifications (all in the case where the user receives a single push notification, but actually has many different notifications available in the remote notifications API).

For example, instead of displaying one large notification (“You’ve received 3 thanks, 2 edit reverts, and 3 talk page messages”), can we break these down into three separate ones (“You’ve received 3 thanks”, “2 of your edits have been reverted”, etc.) with discrete actions for each?

To test this, I updated the logic of the Notification Service Extension in the Notifications Utility test client. The Notification Service Extension allows us to modify the content of incoming visible push notifications. The modify distinction is important: while we can change the content (like title or body) of incoming push notifications, we can’t entirely discard the message – something has to be displayed. Since the PI push service delivers visible checkEchoV1 messages, we will have to implement a Notification Service Extension in the Wikipedia client in order to modify the content of the messages it receives (by making an API request to populate the user’s actual notification content).

An unknown that I confirmed here is that in fact we are able to access the user’s notification center related API to schedule a new local notification from within the service extension itself. A few more things I confirmed are that we’re definitely time and memory limited in the extension. If we don’t call the completion handler in the extension within around 30 seconds, it just delivers the original message it received from the push server.

Pros of breaking the remote notification into local notifications:

• More granular, specific notifications
• Relevant per notification type quick actions

Cons:

• Still can’t get rid of the initial “checkEchoV1” push message message
• Needlessly complicated extra notification breakdown/management
• Limited (<30 MB) memory availability in the extension
• Limited (<30 seconds) runtime availability to complete all operations in the extension

To sum up, while it’s technically possible to leverage local notifications to break up a series of different notification types into separate notifications, I’d strongly recommend against that (unless we have a very strong product case for a very unique notification type) and that instead we just go with the large concatenated notification message to begin with.

A test of the local notifications work is available in this Notifications Utility branch.