-
-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to clear badge icon #4182
Comments
This is based on the recommended setup for PushNotificationIOS from React Native [1], so we might have included it in the next commit, where we fully set that up. But as Greg points out [2], this code is purely using upstream iOS APIs, so it doesn't depend on whether we're using that RN module or something else, so it's fine to do here on its own. In a departure from those instructions, we decide to just pass the thing (`UNNotificationPresentationOptionBadge`) that updates the badge count when the app is foregrounded. This is a necessary part of zulip#4182, but one thing we'll still need to do for that is test that the server is sending the right badge counts to the client. [1] https://reactnative.dev/docs/0.62/pushnotificationios. These instructions are actually missing a required change to the AppDelegate.h, which we take here, having seen it in the instructions for @react-native-community/push-notification-ios (at https://github.com/react-native-push-notification-ios/push-notification-ios#update-appdelegateh). [2] zulip#4163 (comment)
This is based on the recommended setup for PushNotificationIOS from React Native [1], so we might have included it in the next commit, where we fully set that up. But as Greg points out [2], this code is purely using upstream iOS APIs, so it doesn't depend on whether we're using that RN module or something else, so it's fine to do here on its own. In a departure from those instructions, we decide to just pass the thing (`UNNotificationPresentationOptionBadge`) that updates the badge count when the app is foregrounded. This is a necessary part of zulip#4182, but one thing we'll still need to do for that is test that the server is sending the right badge counts to the client. [1] https://reactnative.dev/docs/0.62/pushnotificationios. These instructions are actually missing a required change to the AppDelegate.h, which we take here, having seen it in the instructions for @react-native-community/push-notification-ios (at https://github.com/react-native-push-notification-ios/push-notification-ios#update-appdelegateh). [2] zulip#4163 (comment)
This is based on the recommended setup for PushNotificationIOS from React Native [1], so we might have included it in the next commit, where we fully set that up. But as Greg points out [2], this code is purely using upstream iOS APIs, so it doesn't depend on whether we're using that RN module or something else, so it's fine to do here on its own. In a departure from those instructions, we decide to just pass the thing (`UNNotificationPresentationOptionBadge`) that updates the badge count when the app is foregrounded. This is a necessary part of zulip#4182, but one thing we'll still need to do for that is test that the server is sending the right badge counts to the client. [1] https://reactnative.dev/docs/0.62/pushnotificationios. These instructions are actually missing a required change to the AppDelegate.h, which we take here, having seen it in the instructions for @react-native-community/push-notification-ios (at https://github.com/react-native-push-notification-ios/push-notification-ios#update-appdelegateh). [2] zulip#4163 (comment)
This is based on the recommended setup for PushNotificationIOS from React Native [1], so we might have included it in the next commit, where we fully set that up. But as Greg points out [2], this code is purely using upstream iOS APIs, so it doesn't depend on whether we're using that RN module or something else, so it's fine to do here on its own. In a departure from those instructions, we decide to just pass the thing (`UNNotificationPresentationOptionBadge`) that updates the badge count when the app is foregrounded, and not ask for other things like showing the banner or playing a sound. (This new behavior is necessary for fixing zulip#4182, but I don't think it's sufficient: we'll still want to test that the server is sending the right badge counts to the client.) [1] https://reactnative.dev/docs/0.62/pushnotificationios. These instructions are actually missing a required change to the AppDelegate.h, which we take here, having seen it in the instructions for @react-native-community/push-notification-ios (at https://github.com/react-native-push-notification-ios/push-notification-ios#update-appdelegateh). [2] zulip#4163 (comment)
This is based on the recommended setup for PushNotificationIOS from React Native [1], so we might have included it in the next commit, where we fully set that up. But as Greg points out [2], this code is purely using upstream iOS APIs, so it doesn't depend on whether we're using that RN module or something else, so it's fine to do here on its own. In a departure from those instructions, we decide to just pass the thing (`UNNotificationPresentationOptionBadge`) that updates the badge count when the app is foregrounded, and not ask for other things like showing the banner or playing a sound. (This new behavior is necessary for fixing zulip#4182, but I don't think it's sufficient: we'll still want to test that the server is sending the right badge counts to the client.) [1] https://reactnative.dev/docs/0.62/pushnotificationios. These instructions are actually missing a required change to the AppDelegate.h, which we take here, having seen it in the instructions for @react-native-community/push-notification-ios (at https://github.com/react-native-push-notification-ios/push-notification-ios#update-appdelegateh). [2] zulip#4163 (comment)
#4163 is merged! This is now ripe for working on. In the meantime, back when this issue was new (a few hours after it was filed -- thanks again @aleffert for the report!) we deployed a workaround: the server always sends a badge count of 0. So the current status should be that the app icon is always clear -- that there's never a badge. Before we deployed that workaround, I reproduced this issue myself: So I expect that if we simply reverted the workaround and started sending badge counts, this issue would reappear. We did fix, as part of #4163, an issue that would have caused the badge count not to update when the app was in the foreground. That could cause symptoms similar to this one; in particular it'd be enough to explain the original report in this thread. But it doesn't explain the repro I described at the link above:
|
Running the latest iOS version (v26.29.52) on the latest iOS (13.5.1).
Steps:
Get @mentioned in a message.
Observe badge with a 1 on the homescreen
View message in the iOS app
Close app
Still observe badge with a 1 on the homescreen
Expected:
No more icon badge since I have nothing unread
I also tried opening up with the desktop app as well as explicitly killing the app on my phone.
The text was updated successfully, but these errors were encountered: