Change Details

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: [x] 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 [x] Filter out any unread notifications that whose timestamp is > 10 minutes ago (asked PI and [[ https://phabricator.wikimedia.org/T284238#7246793 | 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). [x] 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.) [ ] Combination of multiple notifications of the same type (2 talk page messages). [ ] 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). [x] 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 [[ https://developer.apple.com/documentation/usernotifications/unmutablenotificationcontent/1649872-threadidentifier | thread identifiers ]] here based on notification type for grouping. Just a bonus we can consider in this task. ===Mocks=== https://docs.google.com/document/d/1V0lvj-guzloDRkaWMcMOFIlxKjavTA_FCo7WjkM_Ia0/edit https://phabricator.wikimedia.org/T274305 ===Dependencies https://phabricator.wikimedia.org/T287298 (for fetching push notification content) ===Related https://phabricator.wikimedia.org/T288773

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: [x] 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 [x] Filter out any unread notifications that whose timestamp is > 10 minutes ago (asked PI and [[ https://phabricator.wikimedia.org/T284238#7246793 | 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). [x] 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.) [ ] Combination of multiple notifications of the same type (2 talk page messages). [ ] 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). [x] 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 [[ https://developer.apple.com/documentation/usernotifications/unmutablenotificationcontent/1649872-threadidentifier | 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

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: [x] 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 [x] Filter out any unread notifications that whose timestamp is > 10 minutes ago (asked PI and [[ https://phabricator.wikimedia.org/T284238#7246793 | 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). [x] 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.) [ ] Combination of multiple notifications of the same type (2 talk page messages). [ ] 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). [x] 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 [[ https://developer.apple.com/documentation/usernotifications/unmutablenotificationcontent/1649872-threadidentifier | thread identifiers ]] here based on notification type for grouping. Just a bonus we can consider in this task. ===Mocks=== https://docs.google.com/document/d/1V0lvj-guzloDRkaWMcMOFIlxKjavTA_FCo7WjkM_Ia0/edit https://phabricator.wikimedia.org/T274305 ===Dependencies https://phabricator.wikimedia.org/T287298 (for fetching push notification content) ===Related https://phabricator.wikimedia.org/T288773