[question]: Possibility to reset and delete subscriptions before initialization

[Danielku15]

How can we help?

The OneSignal SDK stores information about the current subscription and app id in the shared preferences of the app. Unfortunately when the app needs to change the app id, these subscriptions are not properly updated as it tries to reuse existing information.

We have a usecase where we want to choose the app id as part of the user login. Depending on a selection during login, the users will enter app A, B or C (or many others). This is how our business is organized and on the backend we want A B and C to be strictly isolated (for privacy reasons).
I understand that it is not possible to dynamically change the app id on the fly and thats not needed.

What I would like to have is an SDK method for:

• Obtaining any currently known subscriptions before initialization.
• Deleting any known subscriptions from the shared preferences without deleting the subscription on the OneSignal backend.
• Deleting first any locally known subscriptions from the backend and then deleting it locally in the shared preferences.

This operation should be possible before the OneSignal SDK is initialized (but also afterwards). This way on initialization the app will register freshly to the expected app.

I digged a bit into the code and it seems generally it would be easy to offer such an API. All required information is in the shared preferences to call to the backend. I would be maybe also willing to make the required extension in the SDK.

We would also need the same functionality ultimately in the iOS and MAUI SDKs.

Use cases behind these new operations:

• Multi-Tenancy Apps where a user might login into different backends and due to privacy there needs to be strict isolation in the OneSignal push notifiation backend. The app needs a way to clear out any push notification subscriptions during logout procedures.
  • The option to delete or not delete old subscriptoins is a user decision. They might want to receive notifications from multiple tenants or only fromt he newest login.
• When an app wants to change the App ID for migration purposes, the subscriptions are not correctly transferred to the new app in the onesignal backend (maybe this is just a bug?).

Example flow:

1. User launches the app initially and logs into Tenant A
2. We initialize the oneSignal SDK with the App ID A and this creates a subscription.
3. The user logs out.
4. The app will fully restart as the OneSignal SDK doesn't support dynamic changes.
5. The user will login to Tenant B and is asked whether he wants to keep receiving notifications from Tenant A or not (here we use the new API to get the list of current subscriptions).
6. The user chooses to keep the subscriptions to tenant A, and we will only clear the local shared preferences. (this is maybe not 100% clean but the SDK doesn't fully support subscriptions to multiple app ids in parallel).
7. We initialize the oneSignal SDK with the App ID B and this creates a new subscription.
8. The user logs out again.
9. The app will fully restart as the OneSignal SDK doesn't support dynamic changes.
10. The user will login to Tenant C and is asked whether he wants to keep receiving notifications from Tenant A & B or not.
11. The user chooses to not keep any old subscriptions, and we will clear the local shared preferences.
12. We initialize the oneSignal SDK with the App ID C and this creates a subscription.

The solution is not 100% perfect due to current limitations of the SDK not being able to officially subscribe to multiple app ids at the same time. But as this would be likely a bigger topic which is unlikely to get very soon, we would be fine with the minimal solution for now. Our key concern is only the push notifications.

If we would not get this feature, likely we have to strike out OneSignal as possible option for our future corporate push notification needs and look for competitors to serve our needs.

Current workaround:

1. After login we load the app id and subscription IDs via the SDK ourselves and store it somewhere else.
2. We clear the shared preferences ourselves (via the known keys) -> Unstable and not clean. This can change and break any time.
3. We call the API backend ourselves to delete the subscriptions (we only know this call by looking at how the SDK does it today) -> Unstable and not clean. This can change and break any time.

References:

• Delete Subscription Operation here:

  OneSignal-Android-SDK/OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/internal/operations/impl/executors/SubscriptionOperationExecutor.kt

  Line 255 in 43c7d61

  private suspend fun deleteSubscription(op: DeleteSubscriptionOperation): ExecutionResponse {

• Attempt to check app id changes here but reusing existing subscription here.

Code of Conduct

• I agree to follow this project's Code of Conduct