[User Model] Rename notification event listeners

[brismithers]

Description

One Line Summary

Rename notification event listeners based on new naming convention.

Details

• Renamed all "handlers" to be either a "listener" or an "observer" depending on their purpose. All callbacks now have pattern "onXXXXXX" for each callback.
• Make all notification listeners 0:* (some were 0:1)
• Use the terminology "click" instead of "open".
• Add IEventNotifier.hasSubscribers to determine if there are subscribers. A few implementing classes had to add this.
• Replaced complete() pattern with preventDefault() pattern in NSE notification received callback and foreground onWillDisplay callback.
• Add IDisplayableNotification and IDisplayableMutableNotification which adds a display() function to an INotification. This allows the manual display of a notification, when event.preventDefault() is called.
• Internally, rework NotificationGenerationProcessor to accommodate preventDefault pattern. The notification is now constructed when the notification job is constructed and is never copied/altered until the end of its lifecycle.
• Update example application for new naming conventions and patterns.
• Update for new naming conventions and patterns

Motivation

A desire to align terminologies and naming conventions across the OneSignal SDKs.

Scope

This change is primarily a name change within the notifications module/namespace. There are some functional changes related to notification generation processing due to a programming pattern change (i.e. change from using complete() to using preventDefault()).

Testing

Unit testing

Existing unit tests related to notification generation were updated to new expected behavior. Mostly this involved adding new mock calls that were previously not required.

Manual testing

Ran the example app with both a NSE and a foreground lifecycle listener, checking for different variations and manually inspecting behavior:

1. NSE calls event.preventDefault() and returns immediately -> Notification does not show
2. NSE calls event.preventDefault() then sleeps for 40 seconds before returning -> Notification shows after 30 seconds.
3. NSE calls event.notification.setExtender and alters the notification via extender -> Notification is shown, altered
4. NSE calls event.preventDefault() then starts a thread which calls event.notification.display() after 10 seconds -> Notification shows after 10 seconds.
5. NSE calls event.preventDefault() then starts a thread which calls event.notification.display() after 40 seconds -> Notification does not show.
6. Foreground listener calls event.preventDefault() and returns immediately -> Notification does not show
7. Foreground listener calls event.preventDefault() then sleeps for 40 seconds before returning -> Notification shows after 30 seconds.
8. Foreground listener calls event.preventDefault() then starts a thread which calls event.notification.display() after 10 seconds -> Notification shows after 10 seconds.
9. Foreground listener calls event.preventDefault() then starts a thread which calls event.notification.display() after 40 seconds -> Notification does not show.

I also confirmed the notification clicked listener and permission observer for appropriate behavior, though these were just name changes.

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 

[iAmWillShepherd]

I had only a few nits that don't need to block this PR; however, a few points need to be addressed before I'm comfortable approving this. The note about the log should be applied to all files that make use of the format I specified although I only called it out once (this is my style in PR review to call something our once and avoid beating a dead 🐴 )

[iAmWillShepherd]

This should use our v11 docs which are here: https://dash.readme.com/project/onesignal/v11.0/docs/sdk-notification-event-handlers

Note that no one has provided a thorough review of these docs, and they may be wildly inaccurate or even incomplete.

[brismithers]

@iAmWillShepherd pushed up changes. Please let me know if you have additional feedback!

[iAmWillShepherd]

LGTM 🚢

[iAmWillShepherd]

Renamed all "handlers" to be either a "listener" or an "observer" depending on their purpose. All callbacks now have pattern "onXXXXXX" for each callback.

Could you share your thought process on which term to use? At the moment, it's not clear what you mean by their purpose.

[brismithers]

@iAmWillShepherd

Could you share your thought process on which term to use? At the moment, it's not clear what you mean by their purpose.

Realizing these terms are fuzzy in general, this is based on our team discussions to define as:

• Listener: When you want to know when an event has occurred. As an example, you are listening for when a "Notification Clicked Event" has occurred.
• Observer: When you want to know when the state of an object (or property within an object) has changed. As an example, you are observing the changes of the notification permission state on the device.