Skip to content
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

Add discard parameter to preventDefault() #2094

Merged
merged 4 commits into from
May 28, 2024

Conversation

emawby
Copy link
Contributor

@emawby emawby commented May 22, 2024

Description

One Line Summary

Add the ability to immediately discard a notification by calling preventDefault(discard: true)

Details

Adding an overload to the preventDefault method in theNotificationWillDisplayEvent and NotificationReceivedEvent that adds a boolean parameter discard

When true this parameter results in dropping the notification immediately instead of waiting to see if display()will be called within the next 30 seconds.

This is equivalent to calling the completion handler with no notification in the player model SDK.

Motivation

This fixes a bug/behavior where if the app is closed before the preventDefault waiter times out, the notification is not marked as dismissed in the local database and will be displayed when the app is next opened.

Scope

notification will display and received event handling

Testing

Unit testing

added unit tests to validate we don't wait for display() to be called prior to marking the notification as dismissed.

Manual testing

Tested the will display in foreground flow with discard both false and true. Verified that it fixed the redisplay on next open behavior.

Affected code checklist

  • Notifications
    • Display
    • Open
    • Push Processing
    • Confirm Deliveries
  • Outcomes
  • Sessions
  • In-App Messaging
  • REST API requests
  • Public API changes

Checklist

Overview

  • I have filled out all REQUIRED sections above
  • PR does one thing
    • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
  • Any Public API changes are explained in the PR details and conform to existing APIs

Testing

  • I have included test coverage for these changes, or explained why they are not needed
  • All automated tests pass, or I explained why that is not possible
  • I have personally tested this on my device, or explained why that is not possible

Final pass

  • Code is as readable as possible.
    • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
  • I have reviewed this PR myself, ensuring it meets each checklist item
    • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

This change is Reviewable

Must use function overload instead of default parameter due to java limitation. @jvmoverloads does not work when the default parameter is defined in an interface
@emawby emawby changed the title WiP Add discard parameter to preventDefault() Add discard parameter to preventDefault() May 23, 2024
@emawby emawby force-pushed the feature/preventDefault_discard_parameter branch 2 times, most recently from 6c891a7 to 066deda Compare May 23, 2024 19:23
This is identical to the NotificationWillDisplay event parameter and logic in the generationProcessor
@emawby emawby force-pushed the feature/preventDefault_discard_parameter branch from 066deda to 64b309c Compare May 23, 2024 19:24
@emawby emawby merged commit d9c8110 into main May 28, 2024
2 checks passed
@emawby emawby deleted the feature/preventDefault_discard_parameter branch May 28, 2024 18:09
@jinliu9508 jinliu9508 mentioned this pull request Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants