We need to set up a Notification Service Extension to pull from the Notifications API and determine the notification content to display. The fetching and model code can be shared from the data controller created in https://phabricator.wikimedia.org/T287298.

Initial thoughts for pulling content are:

• Fetch all unread global notifications from the Notifications API via https://www.mediawiki.org/w/api.php?action=query&meta=notifications&notwikis=*&notprop=list&notfilter=!read&notnotifiertype=push
• Filter out any unread notifications that whose timestamp is > 10 minutes ago (asked PI and they said this was reasonable).
• Filter out any notification types that the user does not have flagged in the type settings screen (https://phabricator.wikimedia.org/T288688). We could do this via the read API or share these settings via persistence in the app container. (Test first to confirm this is needed - notifications API may already filter this out server-side). Confirmed this is not needed - thanks notifications do not come through if user has push thank preferences column unchecked.
• Filter out any notifications that have already been displayed to the user. This means we persist an ongoing list of [wiki+notificationIDs] in the app container once we display to the user, and check against that the next time we're determining notification content here.

From here, there are multiple ways we need to be able to construct this notification content:

• Combination of multiple notifications (2 talk page messages, 3 edit reverts, etc.) - Will say "New activity on Wikipedia" (see https://phabricator.wikimedia.org/T288773), "Push Notification Content" section.
• Combination of multiple notifications of the same type (2 talk page messages). - I am bundling talk page messages if they are on the same talk page, per Figma mocks. For other situations (mixed talk page messages, multiple thanks, etc.) I am showing "New activity on Wikipedia" text.
• Content of a single notification of a recognized type. We also need to do any extra fetching here to populate rich detail IF we choose to support rich notifications (page summary, article image, edit summary, etc). Showing default notification text from the API here (https://phabricator.wikimedia.org/T287033)
• Content of a single notification of an unrecognized type (maybe it's a future type or something). We need to show default information. (This is defined in subtask https://phabricator.wikimedia.org/T287033).
• Edge case where the API indicates that there is no new notifications. Could be a hiccup between the type subscriptions, the service delay, etc. (This is defined in subtask https://phabricator.wikimedia.org/T285353).
• Content if there was a notifications API fetch failure or timeout (This is defined in subtask https://phabricator.wikimedia.org/T285353).

Sidenotes/Questions

• Apple documentation says to use localizedUserNotificationString(forKey:arguments:) instead of NSLocalizedString when modifying notification content (https://developer.apple.com/documentation/usernotifications/unmutablenotificationcontent) - sync update: We aren't going to worry about this extreme edge case.
• One way to handle potential push service versioning is to fall back to the default content in step 4 if the original push content displays something other than "checkEchoV1".
• I don't think it would be hard to set thread identifiers here based on notification type for grouping. Just a bonus we can consider in this task.

Dependencies

https://phabricator.wikimedia.org/T287298 (for fetching push notification content)

Related

https://phabricator.wikimedia.org/T288773

QA Testing Notes

Please test against Figma Lock screen mocks here:

https://www.figma.com/file/cedgOU5CyOR0UVqtjDOvzE/iOS-Notifications?node-id=549%3A1750

Note we are not doing any long press functionality for v1, so this is purely for testing against the mocks titled "Lock screen notfiications:"