Repository navigation
fix(android-client): reflect swipe-dismissed and timed-out ongoing notifications in the hook - #355
Merged
Merged
Conversation
V3RON
marked this pull request as ready for review
October 15, 2026 12:46
…tifications in the hook Native code now reports when a recorded ongoing notification ends (dismissed by the user or a timeout, or stopped) through an internal TurboModule event, and useAndroidOngoingNotification clears its state when it hears about its notification. start() replaces a dismissed record instead of failing with already_exists, while update and upsert keep refusing to resurrect it. autoStart runs on mount or when it turns on, not whenever the hook becomes inactive. See ADR 0012.
… notification Address review: a start over a dismissed record reuses its system notification id so a still-visible copy is replaced in place, the hook tolerates a missing native event emitter, and the docs, changeset and ADR spell out the remount and start-from-push consequences.
Shows useAndroidOngoingNotification's isActive next to the native status, with start, end, autoStart and a 10-second timeout, to check the hook against swipes, timeouts and cold starts on a device.
V3RON
force-pushed
the
fix/android-ongoing-notification-dismissal
branch
from
October 16, 2026 07:57
2a2872a to
115ef0b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this?
useAndroidOngoingNotification()keeps saying a notification is active after the user swipes it away or itstimeoutMsruns out. The device already records the dismissal (getAndroidOngoingNotificationStatus()reportsisDismissed: true), but the hook never learns about it. Once a notification has been dismissed,start()with the samenotificationIdreturnsalready_existsand posts nothing, so the hook cannot bring it back until something callsstopfirst.This fixes both. The hook's
isActivenow follows the device, andstart()works again after a dismissal. The decision is recorded in ADR 0012.How does it work?
stoporendAll, from anywhere in the app). The hook subscribes when it mounts, then reads the native status once, so a change that lands between the two is not missed. It clears its state when the event names its notification. The event is not public API.start()replaces a dismissed record. A record marked dismissed no longer blocks a new start with the same id: it is replaced with a fresh one and posted again.updateandupsertstill reject a dismissed notification withreason: 'dismissed', so a server push cannot bring back a notification the user swiped away.autoStartruns once. It runs on mount, or when the option turns on, and no longer re-runs whenever the hook goes inactive. A notification the user dismisses stays dismissed while the component is mounted, andend()no longer restarts it immediately. The next mount withautoStartposts it again, since a dismissed notification no longer blocks a start.The example app's Ongoing Notifications tab gets a Hook card that shows the hook's
isActivenext to the native status, which is how this was reproduced and verified on an emulator.Why is this useful?
Apps that drive ongoing notifications through the hook can trust
isActive, for example to show a "Resume tracking" button after the user dismisses the notification, and callingstart()again simply works. Before this change the hook stayed stuck as active and the notification could not be posted again under the same id.