Push to start live activities default LA

[brismithers]

Description

One Line Summary

Add a "Default" Live Activity Attribute model for easy setup of a Live Activity.

Details

This adds to the push-to-start Live Activity work the concept of a "Default" Live Activity. The following new external interfaces are provided for customer app's to use:

• A DefaultLiveActivityAttributes struct which conforms to OneSignalLiveActivityAttributes (i.e. a OneSignal aware ActivityAttributes). A customer app can create a widget with ActivityConfiguration(for: DefaultLiveActivityAttributes.self) to use this provided model. The DefaultLiveActivityAttributes establishes a dynamic dictionary of attributes, able to consume any customer-provided structure of data.
• A new function OneSignal.LiveActivities.setupDefault() which tells the OneSignal SDK to manage the LiveActivity lifecycle for any live activity based on the OneSignalLiveActivityAttributes type. When calling this method, a customer can use both 'push-to-start' and push-to-update notifications to start/update/end their Live Activity.
• A new function OneSignal.LiveActivities.startDefault(activityId, activityAttributes, initialContentState) which allows a customer app to start a live activity based on the OneSignalLiveActivityAttributes type "in app", rather than via "push-to-start" notification.

The default Live Activity is aimed to reduce the complexity cross-platform apps have to deal with when using Live Activities. Prior to this change cross platform apps would have to define their own ActivityAttributes and manage the LA lifecycle through their own cross-platform<->iOS native binding. With this change, the OneSignal SDK owns the ActivityAttributes struct and can therefore manage the entire LA lifecycle on the customer app's behalf.

The downside to using a default Live Activity is:

1. The app will be limited to only one Live Activity type.
2. The widget rendering logic is slightly more complicated in that it is using a dynamically defined ActivityAttributes. For example, instead of rendering a text attribute as Text(context.state.message) it must be rendered as Text(context.state.data["message"]?.asString() ?? "").

Other Changes

• Updated OneSignalLiveActivityAttributes protocol to enforce its ContentState conforms to OneSignalLiveActivityContentState. The new OneSignalLiveActivityContentState requires the definition of an optional onesignal attribute of type OneSignalLiveActivityContentStateData. This will be used in the future by OneSignal to communicate between the OneSignal and OneSignal SDK for each push-to-update notification.

Motivation

Live Activities ease of use

Scope

Live Activities

Testing

Unit testing

• Additional unit tests were added to cover the new functions setupDefault() and startDefault to ensure no regression in the public API will occur.
• Additional unit tests around the decoding of DefaultLiveActivityAttributes were added to ensure the various structures of data can be successfully decoded and used by a customer app's widget.

Manual testing

Using the example app I ensured the default live activity could be started via push-to-start and via in-app with varying structures of data.

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 

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1207424491228378