Live Activities Support

[brismithers]

Description

One Line Summary

Live Activities Support (iOS Only).

Details

This change takes advantage of the newest changes to the iOS SDK, which gives apps the ability to utilize the OneSignal platform to drive Live Activity content-state updates.

See Apple's documentation for more information on ActivityKit.
See OneSignal's documentation for information on how OneSignal and LiveActivities work together.

This change does the following:

• Update iOS SDK to 3.12.3
• Update ApiDefinition to include new EnterLiveActivity/ExitLiveActivity Obj-C signatures.
• Add public .NET method Task<bool> EnterLiveActivity(string activityId, string token) which is used to register the device with OneSignal indicating that the device has entered a live activity. The method expects an app-provided activityId to identify the activity being entered, and an iOS-provided token to be used to drive content-state updates to the device.
• Add public .NET method Task<bool> ExitLiveActivity(string activityId) which is used to unregister the device with OneSignal indicating that the device has exited a live activity. The method expects an app-provided activityId to identity the activity being exited.

Motivation

In support of new iOS functionality.

Scope

This change adds 2 additional public methods, which invokes newly added functionality to the iOS SDK. These changes are not applicable to Android. They also do not effect existing functionality.

Testing

Manual testing

Temporary test code was created to drive the newly created methods to ensure correct behavior. On iOS the expected behavior is the call forwarded to the underlying iOS functionality. On Android the expected behavior is a log message and a failure return.

Affected code checklist

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

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]

This looks good, you note is your description version 13.12.2 it will actually need to wait for version 3.12.3 which has the bug that you pointed out fixed. Should be ready today.