Change Details

Building off of work in https://phabricator.wikimedia.org/T287298, add ability to mark notifications as read or unread, to be called from the notification center or a rich notification quick action. API documentation: https://www.mediawiki.org/wiki/Notifications/API `action=echomarkread` section [ ] Add fetcher method (or audit and lean on any existing ones, see [[ https://github.com/wikimedia/wikipedia-ios/blob/dafd96c0c7c309a3f9ff863d655fcbc27fa590cc/WMF%20Framework/Remote%20Notifications/RemoteNotificationsAPIController.swift#L135 | here ]]) for marking multiple notification IDs as read or unread, using `list` and `unreadlist` parameters. [ ] Add fetcher method (or audit and lean on any existing ones) for marking all notifications as read, using the `all=true` parameter. There's a couple of approaches for syncing with Core Data on this. For method 1 (mark specific IDs as read): 1. The simple approach (let's lean towards this one): Upon user marking a notification as read or unread, pull the managed object for that ID and flip the flag optimistically and save (on background context, so that we can keep the view context read-only). Then make the API call to mark as read or unread. If the API call fails, toggle the flag back to where it was. Note this may result in glitchy UI on this failure case. 2. The harder approach: Each notification object has a `readLocally`, `readRemotely`, and `attemptsMarkReadUnread` flag. The view state is based on the `readLocally` flag. Immediately toggle the `readLocally` flag, then make the API call. If it fails, increment `attemptsMarkReadUnread`. Then have a process that occasionally scoops up all core data objects with `readLocally` = 1 and `readRemotely` = 0 and attempts to mark them in the API again, up until a `attemptsMarkReadUnread` is hit. If this is successful set `readRemotely` = 1 and `attemptsMarkReadUnread` = 0, if it fails, set `attemptsMarkReadUnread` = 0 and `readLocally` = 0. The inverse of this will need happen for marking as unread. For method 2 (mark all as read): We could just fetch all unread local notifications and mark their flags as read. Alternatively we could call the syncing method setup up in https://phabricator.wikimedia.org/T287298 step 7.

Building off of work in https://phabricator.wikimedia.org/T287298, add ability to mark notifications as read or unread, to be called from the notification center or a rich notification quick action. API documentation: https://www.mediawiki.org/wiki/Notifications/API `action=echomarkread` section [ ] Add fetcher method (or audit and lean on any existing ones, see [[ https://github.com/wikimedia/wikipedia-ios/blob/dafd96c0c7c309a3f9ff863d655fcbc27fa590cc/WMF%20Framework/Remote%20Notifications/RemoteNotificationsAPIController.swift#L135 | here ]]) for marking multiple notification IDs as read or unread, using `list` and `unreadlist` parameters. [ ] Add fetcher method (or audit and lean on any existing ones) for marking all notifications as read, using the `all=true` parameter. [ ] Clean out any old unused mark as read code. There's a couple of approaches for syncing with Core Data on this. For method 1 (mark specific IDs as read): 1. The simple approach (let's lean towards this one): Upon user marking a notification as read or unread, pull the managed object for that ID and flip the flag optimistically and save (on background context, so that we can keep the view context read-only). Then make the API call to mark as read or unread. If the API call fails, toggle the flag back to where it was. Note this may result in glitchy UI on this failure case. 2. The harder approach: Each notification object has a `readLocally`, `readRemotely`, and `attemptsMarkReadUnread` flag. The view state is based on the `readLocally` flag. Immediately toggle the `readLocally` flag, then make the API call. If it fails, increment `attemptsMarkReadUnread`. Then have a process that occasionally scoops up all core data objects with `readLocally` = 1 and `readRemotely` = 0 and attempts to mark them in the API again, up until a `attemptsMarkReadUnread` is hit. If this is successful set `readRemotely` = 1 and `attemptsMarkReadUnread` = 0, if it fails, set `attemptsMarkReadUnread` = 0 and `readLocally` = 0. The inverse of this will need happen for marking as unread. For method 2 (mark all as read): We could just fetch all unread local notifications and mark their flags as read. Alternatively we could call the syncing method setup up in https://phabricator.wikimedia.org/T287298 step 7.

Building off of work in https://phabricator.wikimedia.org/T287298, add ability to mark notifications as read or unread, to be called from the notification center or a rich notification quick action. API documentation: https://www.mediawiki.org/wiki/Notifications/API `action=echomarkread` section [ ] Add fetcher method (or audit and lean on any existing ones, see [[ https://github.com/wikimedia/wikipedia-ios/blob/dafd96c0c7c309a3f9ff863d655fcbc27fa590cc/WMF%20Framework/Remote%20Notifications/RemoteNotificationsAPIController.swift#L135 | here ]]) for marking multiple notification IDs as read or unread, using `list` and `unreadlist` parameters. [ ] Add fetcher method (or audit and lean on any existing ones) for marking all notifications as read, using the `all=true` parameter. [ ] Clean out any old unused mark as read code. There's a couple of approaches for syncing with Core Data on this. For method 1 (mark specific IDs as read): 1. The simple approach (let's lean towards this one): Upon user marking a notification as read or unread, pull the managed object for that ID and flip the flag optimistically and save (on background context, so that we can keep the view context read-only). Then make the API call to mark as read or unread. If the API call fails, toggle the flag back to where it was. Note this may result in glitchy UI on this failure case. 2. The harder approach: Each notification object has a `readLocally`, `readRemotely`, and `attemptsMarkReadUnread` flag. The view state is based on the `readLocally` flag. Immediately toggle the `readLocally` flag, then make the API call. If it fails, increment `attemptsMarkReadUnread`. Then have a process that occasionally scoops up all core data objects with `readLocally` = 1 and `readRemotely` = 0 and attempts to mark them in the API again, up until a `attemptsMarkReadUnread` is hit. If this is successful set `readRemotely` = 1 and `attemptsMarkReadUnread` = 0, if it fails, set `attemptsMarkReadUnread` = 0 and `readLocally` = 0. The inverse of this will need happen for marking as unread. For method 2 (mark all as read): We could just fetch all unread local notifications and mark their flags as read. Alternatively we could call the syncing method setup up in https://phabricator.wikimedia.org/T287298 step 7.