This spike is for engineers to answer some questions we have around reading notifications in the app notification center:
It seems like the API only filters on read/unread, so filtering by notification types and projects and searching will need to be on-device. (API is also paged. Filtering + paging will be tricky).
- We could we fetch and persist all notification history right away, which would simplify filtering and searching.
Answer: Correct, the API only filters on read and unread. But it wouldn't be difficult to add that ability per https://phabricator.wikimedia.org/T284239#7231144.
The notifications API response can change depending on which project we're fetching from. notwikis=* returns only unread notifications from foreign wikis, and listing all projects out (notwikis=enwiki|mediawikiwiki...) only pages against the local wiki (i.e. continue can be null even if there are more notifications to see on a foreign wiki), I think the calls will need to be separated out per project, and the results combined to get the single list view of multiple projects with both read and unread from each. See the thoughts around https://phabricator.wikimedia.org/T284239#7231144 and https://phabricator.wikimedia.org/T284239#7233171 for a reference.
What sort of identifiers does it return and could we use that for proper syncing (i.e. marking something as read if it was read on desktop)?
Answer: Notifications are only unique to each wiki (https://phabricator.wikimedia.org/T284239#7231144).
Prototype the fetching and displaying of notifications in OS notification content vs app list screen. Be able to distinguish a new notification for display in OS notification vs one to display with an unread indicator in the app notification center.
Answer: This is done in the push-notifications-prototype branch. With this approach I tried to only fetch deep into the user's notification history as they reached the bottom of the screen, but this felt prone to bugs with filtering and the counts label. I think a one-time bulk import is better, Android has already proved the approach (they do it upon install), and there's been no server load complaints. I suggest doing it the first time they visit the center so that we aren't fetching the history for someone that never intends to look at notifications.
For a new notification to display in the OS notification, I propose we fetch directly from the notification service extension (they will likely have a connection having just received the notification, and I want to avoid more app container database deadlock issues). I don't think there's a case where we would want to display a push notification that has been marked as read, so in this instance a single call leaning on notwikis=*¬filter=!read could get us the data we need.
Could we populate the “123 messages from 6 projects” label from the API (particularly if this is paged)?
- Is it okay if that reflects the local counts and not the server counts?
- Are we only keeping new notification locally or are we recreating Echo inbox historically? If so how far back? If not how do educate users?
Answer: We can populate this from the server if we're only concerned with unread count. (https://phabricator.wikimedia.org/T284239#7231144). Asking for notcrosswikisummary=1 will give us a list of foreign wikis that have unread notifications, and asking for notprops=list|count will give us a global count of unread notifications.
If we're doing a bulk import we could also base this count on local numbers, but these numbers could be way off base during the import. We could still show the numbers during the import and have them update on the fly as we get more data, or hide the label until the initial bulk import completes. I also suggest we maybe have some sort of rotating syncing indicator somewhere so the user knows we're doing stuff.
Can we get the list of projects a user is “in” for Echo, or do we just know about them as they arrive locally?
Answer: See https://phabricator.wikimedia.org/T284239#7231144 for answers. I suggest we determine what wiki projects to fetch from based on their app languages, plus extras like commonswiki and wikidatawiki. We can also make an initial call with notcrosswikisummary=1 to get any additional wiki projects that have unread notifications that aren't already in their app languages. We can use this same logic to populate the projects filter options, or base those options on the local notifications data we have imported.
- Does API support the edit actions from an API perspective? (mark as read, deselect all, mark as unread)?
- Is it marking only items on screen or all items on server (including those that haven’t been fetched yet) as read?
Answer: Yes, see action=echomarkread section here. It looks like it supports marking a particular notification or list of notifications as read, marking all notifications as read, and marking a particular notification or list of notifications as unread (no mark all as unread option). Marking all notifications as read would include notifications that may not have been fetched from the server yet. There's a hitch where sending in a list of notifications to mark as read is limited to 50. If the user selected all 100 notifications on their screen and chose mark and read or unread, we'll need to split up the call into two calls of 50 IDs.