Skip to content

Conversation

nan-li
Copy link
Contributor

@nan-li nan-li commented Oct 9, 2025

Description

One Line Summary

Add receive receipts for live activities notifications, which covers push-to-start and push-to-update notifications.

Details

Relies on the contentUpdates asynchronous sequence to know that a live activity may be update remotely. This appears to be consistently triggered when new live activities are started, and when updates are made to existing live activities.

Motivation

Add analytics for Live Activities

Scope

  • Only for OneSignal-aware live activities, using OneSignalLiveActivityAttributes
  • No new APIs needed for clients
  • Uses existing report_received endpoint with additional properties for the live activity
PUT https://api.onesignal.com/notifications/e09c58de-d062-419a-b9a3-2bffd5918ce8/report_received
{
  "live_activity_type" : "ExampleAppFirstWidgetAttributes",
  "app_id" : "yyyy-yyyy-yyyy-yyyy-yyyy",
  "device_type" : 0,
  "live_activity_id" : "sample-test-la",
  "player_id" : "xxxx-xxxx-xxxx-xxxx-xxxx"
} 

Testing

Unit testing

  • Added 2 basic tests for the request
  • All tests pass locally
tests_pass

Manual testing

iPhone 13 on iOS 18.6.2

  1. Start live activity "in app" does not trigger receive receipts as there is not notification associated
  2. Send a PTU for this live activity and receive receipt is sent
  3. PTS a live activity and receive receipt is sent
  4. Kill app and PTS a live activity and receive receipt is sent

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
  • 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 - ✅ Pass locally
  • I have personally tested this on my device, or explained why that is not possible

Final pass

  • Code is as readable as possible.
  • I have reviewed this PR myself, ensuring it meets each checklist item

This change is Reviewable

nan-li added 5 commits October 9, 2025 09:05
Fix calculation of one day in seconds. This bug had no side effects except keeping old irrelevant data too long.
* Let's arbitrarily keep receive requests up to 30 days. If these requests can't be sent for 30 days, let's drop them. Typically, they will be removed from cache when the request is successful, or fail with un-retryable error.
* Listen for `contentUpdates` as a way to know the live activity has been updated via a notification or "in app". This asynchronous sequence is triggered for all PTS, PTU, and live activities that are started and updated "in app".
* We will check for notification ID to know if this change was generated from a notification and track the receive receipt.
The `testRemoveUpdateTokenWithSuccessfulRequest` should use `OSRequestRemoveUpdateToken` instead of `OSRequestRemoveStartToken`, fix small bug.
* Add a basic tests for the request
* Add this type to the the uncaching test
@nan-li nan-li requested review from a team and jkasten2 October 9, 2025 21:50
@nan-li nan-li force-pushed the feat/live_activities_receive_receipts branch from 3f044ac to 2a2d695 Compare October 14, 2025 21:37
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.

1 participant