Page MenuHomePhabricator

[Notifications] Add app icon badging
Open, LowPublic

Description

Update the unread badge on the app icon itself (on the home screen) to reflect a count of unread notifications.


Product/Design Needs:
[1] Are we going to badge the app icon (on the home screen) with the count of unread notifications at all?
[2] If so, is this a count of all unread notifications or just the ones the user has opted to be push notified about?

Engineering Needs:
[1] Depending on our in-app polling/bell badging design requirements, we need to determine the best point(s) at which to refresh the notification center content/this count

Dependencies

https://phabricator.wikimedia.org/T287298

Related

https://phabricator.wikimedia.org/T288669

Event Timeline

@Dmantena I'd prefer if we did not badge the app icon on the home screen with the count of unread notifications. A simple on or off badge would be preferred for me.

@cmadeo Gotcha thanks – we won't badge the home screen app icon with the count of unread notifications. But I'm confused about "simple on or off badge". What do you mean by that?

@Dmantena ah sorry I meant just a red dot badge with no numbers (eg sometimes you see the red dot, sometimes you don't)

@Dmantena ah sorry I meant just a red dot badge with no numbers (eg sometimes you see the red dot, sometimes you don't)

@cmadeo Correct me if I'm mistaken, but I don't believe that is possible on iOS. On iOS, the red indicator badge on a home screen app icon must include a count of some type.

@Dmantena wow, sorry I literally turn off badges on all of my apps so I
completely forgot that the number has to be there. My apologies. Well,
since we don't have a choice we should include the number and it should
represent the number of unread alerts + notices in their notifications
center (regardless of push subscription)

@Dmantena wow, sorry I literally turn off badges on all of my apps so I
completely forgot that the number has to be there. My apologies. Well,
since we don't have a choice we should include the number and it should
represent the number of unread alerts + notices in their notifications
center (regardless of push subscription)

@cmadeo No worries! It's easy to forget – even when badges are on it's easy to ignore the numbers as noise. So we'll move back to the model of displaying the total unread notifications count on the application badge.

Interestingly (oddly unfortunately even), the precondition to being able to badge the application icon is that the user opts into allowing the system Notifications alert. This is effectively the same alert as in your Figjam flow diagram, first flow, the "System dialog for Push permissions is shown" yellow box alert. I've included a screenshot of what it looks like in practice. Note that there's no explicit mention of "Push Notifications" permissions in this dialog – Apple has changed the copy to just mention "Notifications" generically. There are some minor engineering distinctions, but for our intents and purposes a user must opt in to this system dialog to allow any iOS level notifications/icon badges to display (whether they originate from a remote push notification or a locally scheduled notification).

So, in order for us to badge the application with an unread count, the user must "Allow" that system dialog.

application_badging.png (873×631 px, 178 KB)

Thanks @Dmantena! Wow! There are SO many different permutations regarding notification permissions!

@cmadeo I think a lot of complexity comes from our in-app Notifications Center serving to imitate functionality of Echo on the web, or being representative of the user's total notifications, rather than serving exclusively as something representative of just a user's interested push notifications.

Hopefully our notifications type settings sync tomorrow will help us all achieve more (at least some?) clarity!

@Tsevener Following up from engineering sync – our question was "Because the current Trending events push notification toggle only asks for system notifications permissions for alerts and sounds, how are we gonna handle also getting Badge permissions?"

Check out this flow I prototyped and tested:

BadgingPermissionsFlow.png (1×3 px, 1 MB)

I think our logic for opting the user into badges, alerts, and sounds can work something like this:

  1. Use UNUserNotificationCenter.current().getNotificationSettings, which silently and individually reports the user's current alert, badge, and sound permissions for the app
  2. If the user has not opted into any system notification permissions, UNUserNotificationCenter.current().requestAuthorization for .alert, .badge, and .sound types which will present the system permissions alert
  3. If the user has already opted into .alert and .sound, UNUserNotificationCenter.current().requestAuthorization for .badge which will silently (without a system permissions alert) opt the user into .badge permissions

TL;DR: I think we have a comfortable path forward here.

@Dmantena Nice, that's a relief! Thanks for prototyping this. 🙏

Refresh logic for the bell icon is here, so we should hook into that same trigger for updating this app icon badge.

JMinor lowered the priority of this task from Medium to Low.Sep 3 2021, 5:25 PM