Integrated Notifications API

[maskaravivek]

Takes care of #7.

As of now just a handful of notification types are being handled. We can easily support more notification types based on the need. Heres the list of all notifications supported by commons. https://commons.wikimedia.beta.wmflabs.org/wiki/Special:DisplayNotificationsConfiguration

[codecov-io]

Codecov Report

Merging #1089 into master will decrease coverage by 0.13%.
The diff coverage is 1.5%.

@@            Coverage Diff            @@
##           master   #1089      +/-   ##
=========================================
- Coverage    4.11%   3.98%   -0.14%     
=========================================
  Files         114     123       +9     
  Lines        5298    5496     +198     
  Branches      501     521      +20     
=========================================
+ Hits          218     219       +1     
- Misses       5065    5262     +197     
  Partials       15      15

Impacted Files	Coverage Δ
.../fr/free/nrw/commons/di/ActivityBuilderModule.java	0% <ø> (ø)	⬆️
...ree/nrw/commons/notification/NotificationType.java	0% <0%> (ø)
...w/commons/notification/NotificationController.java	0% <0%> (ø)
...mmons/notification/NotificationAdapterFactory.java	0% <0%> (ø)
...nrw/commons/notification/NotificationActivity.java	0% <0%> (ø)
...fr/free/nrw/commons/notification/Notification.java	0% <0%> (ø)
...free/nrw/commons/theme/NavigationBaseActivity.java	22.98% <0%> (-0.83%)	⬇️
...main/java/fr/free/nrw/commons/utils/DateUtils.java	0% <0%> (ø)
...ree/nrw/commons/notification/MarkReadResponse.java	0% <0%> (ø)
...ee/nrw/commons/notification/NotificationUtils.java	0% <0%> (ø)
... and 12 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b21d1e3...d12e234. Read the comment docs.

[whym]

Thanks a lot for working on this.

Some suggestions from a quick test:

• Any thoughts on the ordering of notifications? Maybe newest first makes more sense.
• The link from a talk page message went to the talk page, not to the section of the message. This can be confusing because in a small screen you wouldn't be able to see the sections below first.

The second point can be left as a future enhancement, but if you are interested implementing, it seems the section URL is found at 'notifications/list/*/links/primary' in the JSON response.

[neslihanturan]

@maskaravivek I was testing your PR. It displayed my notifications on beta debug and it was a great feeling to have access them by our app. However, it displays nothing for my prod debug. I know I have some notifications there also.

• What can be the reason?
• Do we display all of the notifications or we have a since date?
• Can we display read and unread notifications different (not in this PR)?
• I think we should support all kind of notifications after this PR, it is not a big issue.

[misaochan]

Great job @maskaravivek ! Tested this PR on an API 25 emulator.

The good news:

• Notifications all work for me. :)

Changes needed:

• Newest notifications should be on the top, as @whym suggested
• The "Notifications" item in the nav drawer should be nearer the top, possibly between Nearby and About, not at the bottom of the list (sorry, I know this is temporary and will not matter once we get the main screen UI overhaul done, but for the time being a reordering would make sense)
• Deletion messages are not made explicit enough. For instance, in the screenshot below, one of the talk page messages was actually an image being nominated for deletion. Unfortunately, it seems that this might be more complicated than we thought it would be, since it appears that Commons does not actually use "Edit revert" notifications to notify about image deletions, but rather just talk messages. However, IMO it is REALLY important that deletion talk messages are explicitly shown as such (for instance, the email notification I received said "File:Apron from Swiss souvenir shop.jpg has been listed at Commons:Deletion requests"). The user should not need to click on the talk page message to know that it is a deletion nomination.
• Tapping on the talk page message brings the user to top of their talk page, not to the message itself. Especially given that the notification preview doesn't display much information, I think it is important that they are brought to the section with the relevant message.

That all said... I would be on board with merging this PR, and then carrying out the above changes in a separate PR. What do you think @maskaravivek ? But this PR will need to be merged to the feature branch and not master, if we do that.

Things that will need to be discussed further:

• It appears that Commons automatically sends thanks for every edit (I didn't know that). Unfortunately, this might mean that displaying "thanks" notifications might be somewhat pointless, since our app submits an edit for every image. I don't mind leaving it up for now, but we should discuss this in Show user talk notifications #7 .

[misaochan]

Can we display read and unread notifications different (not in this PR)?

This would be excellent if possible. I don't think it needs to be a blocker for this feature though. :)

[maskaravivek]

Thanks @misaochan and @neslihanturan for your review. I have noted the feedback and will take care of these issues in a separate PR. My PR reverts the revert commit so merging it with master will have both the changes ie mine and @neslihanturan's

[misaochan]

Oh, okay. Yeah, I guess we can merge to master and cherry-pick for the next release, then. I will copy the requested changes over to #7 for continuity. :)

[whym]

See also #1112