[User model] Rename Events

[emawby]

Description

One Line Summary

This is a large PR that includes changes to events across multiple features in the SDK.

Details

Privacy Consent - the new method names are:
consentRequired(boolean required) - set to require users to opt in to OneSignal data
consentGiven(boolean given) - set when the user has opted in/out to OneSignal data

Triggers
the addTrigger(s) methods now require values in the key value pair to be strings.

permissionNative
This is a new method that allows you to get the exact permission status for iOS devices (ephemeral, provisional, etc)

Live Activities
The enter and exit liveactivities methods have been moved to their own namespace.

OneSignal.LiveActivities.enter(String activityId, String token)
OneSignal.LiveActivities.exit(String activityId)

Notification Permission Observer
The OneSignalPermissionObserver permission changed function has been renamed and only a boolean is passed as a parameter.
onNotificationPermissionDidChange(boolean permission)

In App Message Lifecycle Events
Instead of four separate listeners apps now implement OneSignalInAppMessageLifecycleListener which has the four methods corresponding to the In App Message lifecycle.

void onWillDisplayInAppMessage(OSInAppMessageWillDisplayEvent event) {}
void onDidDisplayInAppMessage(OSInAppMessageDidDisplayEvent event) {}
void onWillDismissInAppMessage(OSInAppMessageWillDismissEvent event) {}
void onDidDismissInAppMessage(OSInAppMessageDidDismissEvent event) {}

Each event's parameter contains the OSInAppMessage corresponding to the event. (event.message)

The implementing class should call OneSignal.InAppMessages.addLifecycleListener(this);

In App Message Click Events
In App Message actions are now handled by implementing a OneSignalInAppMessageClickListener with the following function:
void onClickInAppMessage(OSInAppMessageClickEvent event)
The click event parameter has an OSInAppMessage and an OSInAppMessageClickResult.
The OSInAppMessageClickResult contains click's actionId and the url, if any, that was launched.

The implementing class should call OneSignal.InAppMessages.addClickListener(this);

Notification Will Display Events
The willShowInForegroundHandler is now the OneSsignalNotificationLifecycleListener which has the onWillDisplay function.
void onWillDisplayNotification(OSNotificationWillDisplayEvent event)
To prevent the notification from being displayed call event.preventDefault();
To then later display the notification call event.notification.display();

The implementing class should call OneSignal.Notifications.addLifecycleListener(this);

Notification Click Events
setNotificationOpenedHandler has been replaced with the OneSignalNotificationClickListener
void onClickNotification(OSNotificationClickEvent event)
The click event has the OSNotification that was clicked and a OSNotificationClickResult
The OSNotificationClickResult has the actionId and the url if any that was opened from the click.

The implementing class should call OneSignal.Notifications.addClickListener(this);

Push Subscription Observer
The OneSignalPushSubscriptionObserver class's function is now named onOSPushSubscriptionChange
void onOSPushSubscriptionChangedWithState(OSPushSubscriptionChangedState state)
The state parameter has a previous and a current OSPushSubscriptionState

Motivation

Update naming for user model api

Scope

In App Messages, Notifications, Subscriptions, Permissions, Privacy Consent

Testing

Manual testing

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 

[fhboswell]

Looks good, didn't personally test.

Reviewed 29 of 29 files at r1, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @emawby)

[jkasten2]

Instead of using classes for events for dart I was thinking it would be better if these were Functions instead. This seems more of what Flutter developers would expect as this is they way their API mostly works too.

Example:

OneSignal.InAppMessages.addLifecycleListener(this);

Instead we have this in the dropbox paper:

OneSignal.InAppMessages.addWillDisplayListener((event) { });
OneSignal.InAppMessages.addDidDisplayListener((event) { });
OneSignal.InAppMessages.addWillDismissListener((event) { });
OneSignal.InAppMessages.addDidDismissListener((event) { });

[emawby]

Gotcha I have updated all of our events to use functions instead of classes.

Reviewable status: 16 of 29 files reviewed, all discussions resolved (waiting on @fhboswell, @jennantilla, @nan-li, and @shepherd-l)

[jkasten2]

The event changes look all good to me now!